 Je m'appelle Patrick Tissiano. Je suis expert en power management du système. Je suis en train de travailler pour la compagnie Belibri, une compagnie d'engineur en Linux, qui a fait beaucoup de choses de développement, de l'architecture et de l'abstrimation. Donc, ce que nous parlons dans la prochaine heure aussi est de la instrumentation de power management. Qu'est-ce qu'on a besoin, pourquoi on a besoin, et beaucoup d'autres sujets. Donc, nous allons fastener nos silbettes et commencer. La gendarme de cette présentation est assez simple. Nous allons commencer avec une petite introduction, expliquer le problème. Et ensuite, nous allons essayer de donner des réponses aux questions suivantes. Pourquoi nous avons besoin de power instrumentation ? Qu'est-ce qu'on a besoin de power instrumentation ? Entre tous ces éléments, c'est déjà disponible aujourd'hui. Et qu'est-ce qu'on a missing ? Nous allons conclure, parler de ce qu'il y a de la prochaine. Et ensuite, il va être ouvert pour des questions. Ok, donc, qu'est-ce que le problème ? Pourquoi est-ce qu'on a besoin de power instrumentation ? La majorité de la communauté Linux est en train de faire face à l'application de power management. C'est la faible de power data et de power instrumentation. Normalement, nous avons tous mis les power probs. Nous n'avons pas pu mesurer plusieurs rails de power. Si nous avons ces probs, encore une équipe de power measurement est assez expensive, ce qui n'est pas disponible pour beaucoup de personnes. Et la dernière main-point ou issue, c'est que nous n'avons pas de data sheets. Nous n'avons pas de power data ou de power data sheets que nous pouvons utiliser sur les SOCs ou sur les plateformes que nous utilisons, expliquant comment beaucoup de power est consommé en temps. Fortunatement, cette situation n'est pas vraiment expected pour changer dans le futur, parce que c'est certain que ce n'est pas l'intérêt de beaucoup de personnes, seulement un groupe de personnes qui travaillent en power management. Mais en fait, la situation est complètement la même. Tout le monde est concerné de développement de devise à développement de l'application. Cette situation nous empêche de... Oui ? Ok, ok. Donc, la situation n'est pas expected pour changer, les boards de devise missent des points propres, la faible de power data sheets et de power equipment expensif. Tout cela nous empêche d'utiliser des techniques customes et d'équipement. Tout le monde est en train de faire la même chose. Ce n'est pas changé. J'ai fait cela pour plus de 10 ans. Chaque fois qu'il y a une nouvelle plateforme, nous avons connu les mêmes problèmes. Donc, cela pourrait être une mauvaise picture, mais en fait, si pas beaucoup peut être fait sur le site hardware, parce que ce n'est pas dans nos mains, sur le site software, nous pouvons encore pouvoir l'instrumentation et donner des outils standard, des outils, je ne sais pas, cela pourrait l'aider. Donc, la première question que je vais essayer de couvrir est pourquoi nous avons besoin de power instrumentation. Donc, la main pour cela. Bien, je pense que l'un des plus importants de l'Holy Grail qu'on a, c'est d'enlever la dynamique de power measurement, ou en fait, l'estimation de la plateforme en termes de power consumption et de batterie, sans besoin d'externe power measurement. Donc, ultimement, nous aimerons couvrir des files de CFS et avoir la power consumption sans avoir à ajouter quelque chose, quelque équipement. De cette façon, aucun développeur, n'importe où dans le monde, pourrait débarquer le power management et faire l'optimisation de power, avec aucune hausse. L'autre soumise, la deuxième soumise, c'est d'aider les gens à détecter et à débarquer les power leaks. Avec les power leaks, on veut dire qu'il n'y a pas de nécessaires de devices qu'on a ou d'autres states de power consommés. Donc, ça augmente la power consumption, réduit la batterie de la batterie et ça doit être tracé. Donc, un exemple, il y a des clocs, des devices de running, des clocs d'adéquation, des frequencies d'adéquation de CPU ou d'autres states de CPU qui n'ont pas été entraînés ou d'autres réguliers qui ne sont pas possibles ou d'autres GPIOs qui n'ont pas été mises dans des states impédants. Un exemple comme ça. Pour les gens qui utilisent la batterie, c'est l'issue régulière que l'on présente. Avec des outils standard pour l'instrumentation de power on pourrait enlever la capture de la trace de power et on pourrait post-processer. Donc, pour l'instant, on extracte les statistiques. Si vous avez une trace de power consumption et des transitions de power state d'une certaine façon, et puis on extracte les statistiques comme combien de transitions y a-t-il, combien de temps les CPUs ont été spent en ces states, combien de devices ont été utilisés, etc. Donc, ça serait super efficace pour la débrugnée de power et ça pourrait également enlever l'automation de la régression de power. Avec ça, je veux dire que ces outils pourraient être intégrés par des frameworks comme KernelCI, PowerCI, Fuego. Nous pourrions capturer les traces de power, analyser les statistiques extraites et on pourrait comparer avec les billes précédentes automatiquement. Un autre propos qui ne peut pas arriver immédiatement dans notre mind c'est de la modélisation de power. Pour ceux qui travaillent avec les vendeurs SOC, vous devez savoir que souvent, quand les vendeurs sont en train de organiser la prochaine plateforme, ils tentent de modéliser la consommation de power selon la plateforme existante et des numéros updates. Et souvent, ils utilisent des tools très complexes qui tentent de reproduire ce qu'est le hardware ou ce sera. Dans cette zone, si nous capturons une trace de power, avec tous les states de power et les transitions, et les rates de clés, etc. Nous pouvons juste présenter ces traces avec les data de power updates et nous devrions avoir la consommation de power et nous pouvons aussi imaginer en faisant ça, comparer les plateformes directement avec la même trace. Pourquoi c'est possible, c'est aussi parce que nous n'exprime pas beaucoup de codes pour changer d'une génération d'une autre, c'est-à-dire que si le périphère dans le SOC n'a pas changé, le chauffeur sera le même et l'app sera probablement le même. Il sera plus accurate que les autres softwares modèles que nous pouvons utiliser. Parce que c'est une capture réelle sur le hardware. Une autre graine holique, au moins pour moi, est l'envoi de la police de power management. Vous devez savoir que la police de power management, les gouvernements de la police de power management, les gouvernements de la police de power management, qui se sont emmenés aujourd'hui dans les canons de Linux, sont en train de travailler dans un édition ouvert. Ils sont typiquement sample des points de data dans le système et, en basant sur des médecins, ont des décisions. Mais en fait, c'est pas la mesure de ces décisions, et il ne sait pas. Maintenant, si vous pensez que les policiers peuvent obtenir des power estimations de la plate-forme, maintenant c'est un lois et ça pourrait refaire ses décisions et les updater dynamiquement. Ça pourrait ouvrir la porte à des policiers très avancés, incluant des policiers de self-learning, des techniques de deep learning. Donc, finalement, peut-être qu'aujourd'hui, on ne peut pas faire de la fin de la tuning, de la fin de la tonnage de la fin de la tonnage, on juste laisse les policiers sur la plate-forme et ça pourrait être fait. C'est un rêve. Ok, si nous ne voulons jamais évaluer les power-instrumentations, qu'est-ce que nous avons besoin ? Tout d'abord, évidemment, nous avons besoin des points de power qui signifient quelque chose dans le courant sur la plate-forme qui nous notifiera quand il y a une transition de power-state. Donc, ça inclure les transitions régulaires, les transitions de power, les transitions de clocs, les domaines de power, la fréquence de CPU, les idées de CPU, la change de state de state, les GPIOs, tout ce qui est lié au management de power. Et ces événements, évidemment, pour avoir un tracement, ils seront timestampés pour être utiles. Qu'est-ce qu'il y a ? C'est le point de tracement. Nous avons besoin de data de power-instrumentation qui signifie que je veux dire que combien de power-device consomme dans un state de power-state à tout moment. Donc, c'est une sorte de database où vous pourserez avec un nom de power-device et un state de power-device Ceci inclure les peripheraux internals de SoC donc le GPU, la CPU, le RAM, les contrôles I2C, les peripheraux I2C, UART, GPIO, tout. Mais aussi, tous les peripheraux qui sont embêtis dans votre plate-forme mais pas partie de SoC. LCD display, wireless controller, flash-devices, sensors, je vous donne quelques exemples sur le device UART Nous voulons savoir que le device UART consomme 5 micro-watts quand il est suspendu et 100 micro-watts quand il est active. C'est le même chose pour un device EMN-C. Le dernier point que j'aimerais vous proposer c'est le tour de power-analyses. C'est super cool d'avoir toutes ces données, les traces, les data de power-instrumentation Qu'est-ce que nous faisons avec ça ? Comment nous détenons et analysons toutes ces données sans un outil qui fait le travail pour vous ? Nous ne voulons pas être dans cette situation comme réveillant les x-values des registres et décider d'ouvrir un TRM ou un datasheet pour comprendre ce qui se passe. Nous voulons quelque chose qu'on peut comprendre et qu'on peut utiliser pour détenir toutes les choses que nous voulons. Donc ces tools vont post-processer la trace de power-analyses et extracter des statistiques éventuellement protéger la trace et d'autres choses. Ces tools vont être génériques et de grosses plateformes parce que si nous voulons un outil standard, il doit être génériques et de grosses plateformes. Comme note, des vendeurs ont déjà offert des outils custom de leur propre. Par exemple Qualcomm, un profiler Snapdragon ou Google's Android Cstrace. Donc, ils sont tous recueillis d'Android et d'ADB. Donc, nous ne pouvons pas l'utiliser pour la mainline, pour exemple. Si nous sommes juste en train d'avoir un système BZbox, ce n'est pas utile. Ok, donc, entre tous ces éléments, qu'est-ce qui est disponible aujourd'hui ? Est-ce qu'il y a quelque chose que nous pouvons utiliser en même temps ? La bonne chose c'est que, oui, il y a quelque chose. C'est la trace de power-analyses. Donc, le kernel par la trace de power-analyses est en fait déjà offert à nous toutes les pro points que l'on a fait previously. Runtime PM, Cloud Management Events, CPU Power Management Events, Platform Suspense Resume Events, Regulator Events, GPIO Events, tout ça. Nous avons tout le data qu'on a besoin. Et nous pouvons aussi, si quelque chose est faible, c'est assez facile d'y ajouter. Et si nous voulons faire quelque chose custom pour la plateforme, nous pouvons aussi facilement le faire. Donc, comment nous collons les événements de power-analyses avec Ftrace ? Bien, d'abord, nous avons besoin d'améliorer la trace de power-analyses dans le kernel config file. Donc, c'est les deux flags listés ici. Ensuite, vous buildez votre kernel. Et c'est tout. Vous avez besoin de monter le debugFS. Et c'est tout. Maintenant, vous pouvez faire des échos pour que le debugFS entre l'entrée et que vous avez besoin de tout. Donc, pour l'instant, vous avez besoin d'améliorer l'écho-1 pour ce file de power-analyses. Et l'événement de power-analyses commence à être tracté immédiatement. Donc, vous devez remettre la trace de power-analyses avant d'améliorer la trace. Et ensuite, vous pouvez évaluer la trace. Vous pouvez écho-1 dans ça. Et c'est tout. Vous avez votre trace. L'impact de performances et de power-analyses est, je dirais, réduit au minimum ce qu'on peut faire avec une solution de softwares. C'est à dire qu'il va y avoir un printk dans un ram buffer. Donc, ce n'est pas supposed d'impact d'une transition de power-analyses. Donc, pour l'éducation et d'autres propositions, ici, j'ai utilisé l'écho-technique. Mais en fait, il y a un tool binary qui s'appelle trace-cmd qui fait tout le travail pour vous. Ici, c'est un exemple d'un F-trace avec des événements de power-analyses. Donc, si j'ai un point, je ne sais pas si vous pouvez le lire, mais il y a des événements de CPU fric d'événements de CPU ici. Donc, c'est un trace que j'ai collecté sur une vraie plateforme. Et l'idée derrière ce trace, c'est que on va écrire des outils qui peuvent le lire et faire le travail pour nous. Ou partiellement, au moins. Ici, il y a juste un peu de références pour ceux d'entre vous qui seraient intéressés à savoir plus de F-trace. Et c'est ça pour les éléments disponibles. Maintenant, let's talk about what's missing. Obviously, the power database I call it database. So that's the power consumed by a given device in a given state. We are lacking a lot of public data like this today. But it is critical, obviously, for our job. We may get some battery life for some given use cases. For instance, for smartphones, usually we have battery life data. But that's all. And it's not sufficient. We'd like this database to be generic and multi-platform. So that we have a standard tool that is able to post-process it. So I gave a very basic and dumb example here. It's just a text file with describing the device, the name, and the power consumption given states. And the idea is that we could have a tool that would take the F-trace, take this data and put everything together and draw us the power consumption. You may know for people dealing with Android that it has a similar power database already. It's called Power Profile. And it's a XML file defined in the link I have highlighted here. So Android is already doing that. It's not complete but it's already a good start. And this is helpful for Android to display all the battery statistics you may find in the settings application. So on the previous slide I described a simple text file in user space, in the file system. But actually if you think a little bit more, device tree could be a good candidate as well to store this data. Why? Device tree purpose number one is to describe the platform to the counter. So more or less it's job to describe the power consumption or to store this information. It's already there, it's generic, stable, multiplatform, it is mandatory when you create a new platform it is mandatory to use device tree and for the existing platforms they are being converted slowly but still they are progressively getting converted. And what would it mean in terms of implementation? Maybe just as a new attribute to be added to the existing attributes. So here is an example. I'm not saying it's the right way to do it but you have your device tree file, your DTS file, the existing devices with the existing attributes and for instance for the UART we could add information of the active power and suspended power and given that we would be able to if we have this information for all the devices of the platform then we can rebuild the power consumption of the platform. Almost for free. The good thing about having this information stored in the device tree is that it may be reused for other purposes than power instrumentation and also at runtime. So for instance, first example with Ftrace we could add this information to the logs and the kernel power management policies they would be able to use it and so take better decisions and again we would enable more close loop heuristics with self-learning policies or deep learning algorithms. Device tree is also accessible from user space which means that it's not blocking us from developing a user space tool if we ever put this information in device tree. I would say that the downside may be that it may be more difficult to maintain as part of the kernel because it wouldn't involve more people more discussion and the question could be how would maintainers would validate the power data. Ok. What else is missing? So let's say we have the power trace available we have the power database we need tools to test for us So I would imagine a tool a regular command line tool that would take the power trace take the database and reformat all this for all usage it could generate automatically power statistics and it could reformat the power trace for standard plotting tools obviously it could be a multi-platform and it could run the good thing is that it could run on the target device or on a host PC that would be super useful for regression tracking continuous integration and automation because that could run automatically on build servers and test reports could be published and we could imagine that the build server could also notify people whenever there is a power regression highlighting what changed compared to previous version quick example you give the trace and the power data to some tool and it gives you immediately the minimum power consumption or for the given trace the min, the max, the average value the time the CPU the average CPU loads the time the CPU spent in value states the CPU frequencies used the active device count etc. the total number of power transition etc. that would be super useful for comparison because let's say ultimately someone would be able to say ok this is the optimum configuration for power of my platform he could save this data and then everyday continuous integration servers would compare with the target goal and then highlight where it's good where it's wrong that's not sufficient so that's a static analysis of power trace but for us human usually we need something more visual and we need to understand all the dynamics of the platform so for instance people using kernel shark for performance tracking can clearly understand this so it would be very interesting and helpful for us to have some sort of power chart that would highlight all the power states on your platform not just the power but the power and what was, why we have this much that much power at that time so I sketched a quick exemple of smart plotting tool for power instrumentation on the top on the upper part we have various devices and the states the power states of these devices over time the CPU load CPU speed the number of CPU that are active over time clock rates devised power states active device counts so the number of devices in your system that were active at a given time and some GPI values so that's an example there might be other useful data but that was just an example so here are the different power state transitions over time and below the corresponding power consumption trace that has been estimated by R2 so I would say that we could have this very easily today but what I find I would say the next step is that if I could point to a given data point on the power trace and it tells me it would tell me immediately what has changed why we have that much power consume here power consumption at that point of time and then what has changed now we know that we had this rush because the GPU got turned on so we enabled the clock of the GPU we enabled one CPU and that's the running applications you may know it a little bit popular so if I point another data point why it is going down because the GPU is getting relaxed we don't have this today and I think if we were able to provide this tool that would be super useful for us because we would know immediately what are the device states at any time and why we have a power peak or not so let's try to summarize what has just been presented on the bright side the great Linux kernel has all the infrastructure in place for power instrumentation we have a trace that is tracking for us all the power events, the scheduling events and the performance events it's easy to add new power events if anything is missing and the tracing impact is limited on the dark side we are missing the power consumption data it may be hard and long to get and we are missing I would say the post processing tools regarding the power consumption data it's ok we could deal without it meaning that we could still rely on some external equipment to measure the power consumption and so we'll need to do some work to synchronize the power consumption trace captured by our external equipment and the ftrace data but that is doable so the next step is probably to get back from the expert in the room during the ELC to sense if there is an interest for that and if it's a good direction to go, to follow do more work on the power database part try to decide between device tree or a regular user space database that's gonna take some time developing the post processing tool may not be that difficult particularly the first one that is just reformatting the trace that should be quite easy and quick to get and then the plotting app may take a little more time and ultimately we would like these tools to be the de facto standard tool for power debugging ok, that was it and now please ask for questions yes quite so it seems there needs to be more states than active and suspended for each device and if that data gets added then we should also add data describing what SOC power states that device might block because that way you can with the tracing data you would see the blocking devices also for entering deeper idle states which we are completely missing right now and it would be done in a generic way that way yes, clearly we may need to add more power events to Ftrace I guess what we have today is already good for get things started and then we'll upgrade I didn't mention that a lot in the presentation but there are many challenges in this if we ever want to get to this state like getting all the power data making sure we don't miss any any information to get a very accurate or as accurate as possible power chart there are many challenges but maybe we can if we don't get something super perfect maybe still we can get something that helps us yes one interesting thing if you had a power database is also to think about peripherals so if you plug in a USB drive that thing never ever goes to sleep that can block the whole system from going deeper so your power database either has to know about a whole lot of things perhaps you probably can't build it into the hardware to tell it at runtime but something like device tree which maybe is fairly static could be tricky there because you don't even know what might be plugged in later the other thing is I think besides a trace tool a live tool like power top basically would be very cool yeah you are absolutely right one thing to point out is I think you said that there's no on most devices there's no way to measure the power but I think there actually is there's smart battery and so smart battery can usually report the current or wattage depending on how you have it configured and it's really rough because it's just full system power but with that you could sort of figure out a lot of the things you're looking for so you could turn on a clock and then see how the overall system power draw got adjusted it would take a long time and it's really rough so you'd have to you know, run it for 20 minutes in one state and 20 minutes in the other state and then figure out how much power was taken out but you could eventually figure it out that way especially bigger power draws so you are right for the most power consuming devices of the platform but for very tiny peripherals like UART or whatever it's probably not possible to get it from the battery because it's going through so many stages like if the consumption is 5uW there is no way you know it at the battery it's completely it completely disappeared but for the big ones excuse me potentially yeah it depends on the use case for instance if you are tracking a very low power use case like either or when the platform is suspended then it becomes critical it's a matter of scale but you are right we were able to do some useful stuff on a big little system just seeing what the power contribution was on the big versus the little that can be used I think an interesting question is whether everyone kind of cooks up their own stuff to figure out the power consumption when you are measuring at the battery of different components and I wonder if there is interest in trying to do some generic way of gathering that data and trying to figure out the deltas between test runs and isolate power consumption of individual components don't forget that ultimately we don't want to do this job we want the SOC vendors and platform vendors to do it thank you I have a couple of points for the offline processing of the trees as part of the energy we are shelving development we develop tools that actually parse a trace and then we do basically a statistic analysis on top of it we for example we already have no frequency analysis cpuado states analysis the only thing we actually have some prototype code that actually tries to compute a power estimation of from a trace so basically what you already talk about we probably have already something available on the tab so I guess I mean people can contribute of course they are called lisa and trappie but I'll give you links and actually another point was on the online instead analysis so actually because yesterday I followed the nice presentation by Tom Zanussi from Intel he's working on he's working on creating these histograms for latency tracing the nice fact that the thing is actually able to actually do deltas of events during a trace and then maybe trigger events when I don't know a certain threshold is actually overpass so I guess ideally we could actually do the same but looking at power consumption so maybe you can define your threshold of power consumption and then when you do regression testing they actually say ok if I on a certain time I cross the threshold please give me like a trace of what happened in the last couple of seconds so then I can go back whatever another thing Patrick you mentioned storing the power consumption in device tree and I know there was some effort to do that for CPU nodes what happened with that currently what we have in mainline is the capacity so how much capacity CPUs at the different states can actually give and the next step will be to add power to that thing it seems I mean we discuss this thing at the last the last numbers it seems to be positive actually the capacity thing was the most controversial bit because it's not I mean it is something physical but it's not like power so the power aspect should be probably easier to get done so yes thanks ok no more question ok thank you so much