 OK, now my name is Kimo Wünig, my name is Wulge Macht. We are both working for the mobile devices team at Susie Linux and Nurembed and today we want to present our power management infrastructure we are using which has been developed over the last few years. After 8pm was completed and 8pm I was introduced we got a lot of systems which is not working out of the box using the Nurembed power management piece and we are required to build an architecture to get as most of the systems running out of the box with the power management. I think we are giving a short overview about what we are going to talk about. With the cut on the left hand side I think you can read it anyway. First of all I will give a short overview about Linux power management in general which will be moving the kernel and the user space. And then I will talk about the PowerSafe architectures picture and what applications we use to make use of the PowerSafe or PowerSafe management subsystems. And this will be followed by a short introduction to the new thing of runtime device power management. It will be introducing what you are currently able to do with putting devices into some other sleep state at runtime and thus you are able to set power as well. Afterwards we will have a live demonstration and will demonstrate how much power is actually consumed and will make use of the power management features. At the end of the demonstration we hopefully will have shown that power management is very efficient when we use it. And the last thing we are going to present is a short what's next section where we are talking about various things which are coming up in regards to power management of the Linux. Now Linux power management is part of the kernel for sure. It provides all the subsystems and interfaces we are using with our project architecture to make use of it. One of the most important things is the CQ frequency scaling that you are able to switch the CQ frequency while at runtime. And nowadays if you have got a dual core machine for example you are also able to switch cores on and off while running the system without turning it off. The next subsystem will be ACPI. It provides information about every styles of components of the system as well as it gives interfaces about triggering and some actions to the subsystem implemented by the machine. And we have another subsystem called device power management because it's like in the subsets we are able to trigger the power state of the specific device that uses the system as it does. This layer is encompassed by a second layer. We are having the power set team at the top and Paul as well which are directly talking to the core interfaces and they are on the other end talking to the client. We are having it right there. Let's see how they are communicating with each other. We have two main IPC inter-process communications. The first thing would be system cores between the power state team and Paul. They are using both system cores to access the core interfaces like CPU, FAC, ACPI and the device power management. On the other hand we have the clients who want to communicate with the team and this is basically all the client dealers nowadays. We have the clients communicating with both with the power set team as well as Paul and we have additionally power set to speaking to Paul. Here we are moving some functionality from our power set team which has implemented stuff like battery calculations to Paul to have power range. Now that's it for the graph overview. We now have some information about the power set architecture. Okay, at first we have the power set team. It's a root team caring about things that need root privileges like caring about multiple batteries and performing corresponding actions. For example, if the battery runs low and suspending the system and switching CPU to NC and of course doing runtime device power management but this is currently still under development. We both support an ADM and ACPI in the same manner. A second big and important part of the team is its scripts. Why do we use scripts? For example, for unlawed modules or restarting services and why did we put this functionality into scripts? They are easy to customize and you don't even need a compiler. You can simply give a user a new part of a script or you can say you can change line 20 and so it's very easy to provide new functionality. You also handle hotkeys in those scripts and that makes it possible that users can define own actions on window-specific key presses and starting an application or something like this. On top of the power set team we have a set of libraries. At first the general power set library summarizing battery information calculating CPU load or reading out throttling information then we have two further small libraries providing convenience functions and for communication with the whole demon or for communication over the deepest demon. These libraries are used by our clients to present the power set features on the desktop. For example, they interact with the demon, triggering suspense states, setting CPU quality, setting different power-saves themes. The other main part of the clients are its own implementations like how to suspending the system after a specific time the client has to care about whether the user is idle on the desktop and then the client triggers the spent over the power-saves libraries to the demon. The client also implements other features like locking the screen when the lid is closed or showing messages from the demon to the user. We have a key power-save for the KDE desktop, a WM power-save for Windows Maker or GDM power-save and we also have a command line application that makes it possible to fully control the demon. That can be helpful on servers where you do not even have a desktop. Now I want to give a rough overview of how our scheme architecture works. I picked out our main two schemes that are in our default configuration, namely scheme power-save with running embedded battery or scheme performance when the AC adapters black in. I also put some example features around those schemes and now because you can configure the demon as you like you can put those features into the schemes put them inside like you want so you can compose your own set of schemes. It's also possible to create completely new schemes it's really easy and this can be very interesting for the user and he can create his own custom schemes that shifts his needs. You might expect that the positive demon of this architecture is only a solution for Susie but that's definitely not true. We already got a lot of feedback from other distributions and here you see the distributions and we know that the positive demon works and the architecture works and there are also packages available from those distributions already. Okay, let's hand over to Demo. Next thing we are going to talk about is runtime and last power management. As I look at what we are currently having it's like pushing the global system state to suspend to disk or suspend RAM or standby something and we are also able to switch to CPU frequency it's also quite easy to adjust on most systems we are also able to adjust the brightness of the display but what will we actually get for the case of switching the global system state because we are having time as we are able to restore a system as we lessen it when we suspend the system but when you look at CPU frequency and LCD brightness we are only saving power on the expense of something else you are losing performance when switching to a low frequency and you are losing the readability of the screen when you are switching down the brightness So next thing which is coming is runtime and device power management here you are able to switch off devices which you are currently not using and thus you are not having any loss when you are doing so imagine you are on the train or somewhere else where you have no AC adapter next to you so if you are not using the USB or sound subsystem at all then you are able to switch off those devices and even if they are currently not used we will see in our craft next on the live demo they are consuming power because they are powered up and with runtime device power management you are actually able to suspend the whole device and then you are saving power in the details about it the ACPI specification gives us four sleep states for the device power management D0 to D3 while D0 is the fully powered state the normal regular state which is mandatory and the D3 state is the off state where the device context is lost and you need to re-initialize everything after you power on just saying now the two states are not mandatory as the others they are optional and they are mostly not implemented on the rest of them so it's actually your next phase with the echoing of the numbers and species of SEPAR that's wrong, D0 to D3 don't represent these states they used to represent PCI states but now they represent off states but they are now using the D state on the PCI and then D0 to D2 to CIS and then you are kind of using an old kind of 10.0 the next thing is the exam pop switch to the power state if you are correct I think so on the recent course you only got a 0, 1 and 2 multiple 3 state and the two would correspond to D3 yeah, exactly so on an old system you would use the second line first of all you have to identify the device you want to power down and afterwards you are using an echo to the SOSFS path to execute the switch off the power device which is the power state of the device on recent course it would be echo, dash and 2 to get to the D3 state which is mentioned above as always we don't want users to go to a terminal to hack these states to activate the power management the run time device power management and thus we have enhanced our power set architecture to do this in the power safety mode and it's already implemented and this is going to be configurable by using a client of the power safety mode it's also important to make that this interface is likely to change, there's currently development going on then so because don't be sure that this will be the way you power down the device in the future so what we have actually done to test run time device power management to test the consumption we have a test set up you can, you have one target system that gets messaged you can see this in front from your point of view in the right the laptop will remove the battery of the laptop to get real accurate values to not measure the charging of the battery we have an ampere meter connected to this laptop to record and measure these values and we have another system running that runs a software recording the values and displaying the values in this case it's QGDMN and now I put out an example of a module of a device the IPW2100 module you see a graph and how our test results look like at this point the device is fully powered oh I have to mention that in the y-axis you see the ampere the volts are constant we measure it with 20 volts the az adapter provides 20 volts and so we are measuring the ampere on the x-axis is the time in seconds so in the beginning we are about 0.820 ampere at this point we power down the device you can see a tension peak the line increases that's the price we have to pay for powering down the device further on the line drops and you can see that a lot of power can be saved by only suspending one device and the IPW2100 module is a very good example of how much power is consumed without the device even used and these are about an example only the line drops to about 0.77 about 0.1 ampere finally the device is powered on again and it returns to an initial state about and the peak in the end is just the test ended at this point so now we have a live demonstration using the power measurement functionality any questions so far? we are having a set up it was not obvious from your presentation so far, I've probably missed a little bit of picking but anyway, how you detect the idle device what is the way? it's probably being done by the user on interaction so you are saying ok I don't want to use sound at the moment but it's going to be a far end of the implementation to see whether the device is being used and if not, it should be powered on so it's kind of an obsession level in a way that at the moment you have to say ok, switch down the USB subsystem for example and then version wise start going central ok and now you are fixing that that you are going to switch off the device switch off the device we are sending it to the USB 3 depending on the driver or the hardware it's going to be off or not ok, first of all we are running at full speed we have a system running with 1.6 TRs we will see it when the system is up what you cannot see is that the brightness of the display is at the maximum so we are currently using the most power as possible and we also have deactivated the device runtime with device power so we should have the machine as it would be powered on the desktop when we are running on AC for example we are using K-PowerSafe to show the interaction between the client and the device and in this information level we are running the information of the system I'm not sure whether you can read this stuff except that we are running with the performance scheme meaning the high-secure frequency which in contrast to the high-secure frequency it's at the maximum it's at 1.6 TRs we have our battery set we have brightness level being at 100 and one hand power management is being switched off and currently our system if you can start the machine we are missing y-axis on the left-hand side you will have to look at the values and you will soon see some graph hopefully it starts now if you look at the graph that's the value being consumed that's the 1.05 do you mind taking it on the board? right now the first thing what we are going to do is we are switching down the CPU frequency down to 600 MHz and we will see how much power this will save there you can see we are running at 600 MHz power consumption of the whole machine you can have a look at the setup afterwards it's quite easy and now we are seeing that we are dropping down to 1A which is already a gain of 0.4A simply by switching down the CPU frequency about 1.1 ok now the next thing you are not able to see because of the display thing I will lower the brightness of the display you won't see on the screen but trust me the screen of Wi-Fi gets darker and darker and when you are looking at the graph it's falling down, it's dropping and even though I've only run to 50% of the brightness you will see that you are almost gaining as much as with the switch of the CPU frequency which might not be obvious but you are thinking about what your gain is and we are switching the brightness further down to 0% it's still a little bit under it goes down a little further it dropped to about 0.8 and as a last step of those three steps we are performing we will switch on the run time device power management and in the moment we have a switch up for the test setup which will deactivate the USB sub-system will deactivate the sound sub-system as well as wireless card and the line adaptor as well and this will be created at the moment by switching the profile at once just integrated it for the test another thing we have added peak and it's falling a little a little bit more another peak for another sub-system that is power down too scared is about to drop but now it's dropping that's what we have expected we are setting another seal about 1.5 we have better results depending on the machine the device drivers are smart enough to detect that the device is induced but already power down the device is on a less consuming state so we have been testing several machines and it's very dependent on hardware whether they are gaining anything or much so that's how we do it 7 5 and G is in the end so we have saved about 6.5 and here 0.6 0.6 almost 50% ok what we are actually I'm using at the beginning with full throttle we had about as I already mentioned in 20V are consumed we have P equals U multiplied with I and so we have in the beginning we have 20V multiplied with 1.4 and here it makes 28V so in the end we had 20V multiplied with 1.0 0.75 and here which could make 15V what's at the end and you can see we nearly saved the half of the actual power consumption here in the beginning which I think is really great what you can achieve with power down devices and all those power machine functionality the thing why we choose to have a setup like this one is that the APACS system already provides information on how much power is consumed or the battery information is consumed but this is not accurate enough so we were forced to have something like this for getting real results for several machines we were investigating and it was a live demonstration so we have a short introduction of two new things coming up in power management first thing would be what part? first part is user space software I just want to give a very rough overview about what it's all about I do not want to go into detail it's a very new technology it's already in UAMM kernels and hopefully will go to mainline soon until now software suspend was done completely inside the kernel the writing of the memory image and so on and now with the user space software suspend you only have the kernel only provides the kernel interface have snapshot currently and the kernel provides several control controls for this kernel interface like natural freeze to freeze processors or snapshot available swap to query the kernel about the available swap space and there are several others and so now the complexity of writing the image and so on is shifted to user space currently there are two main tools one called suspend for suspending the system writing the image and one resume for resuming the image resuming the system so it's an original state this has some advantages this makes things like compression or encryption or boot splashing possible while suspending the system to disk that's just a rough overview of what's new and we already did some testing and it seems to work and we hopefully can use it in the future I think next thing we will be investigating is a fetch called Gintx at the moment we have a static value for hearts for the timetix issued to the CPU exactly and with Gintx this is going to be a variable which is dynamically chosen and this allows the CPU to enter the open saving mode C3 defined by the ACPI specification more often and thus we are very empowered we have a colleague who was testing the Gintx patch on several machines and the gains are quite cool but the problems like losing interrupts remain and they definitely have to go away for integrating Gintx into a regular working environment that will be possible I think that's all first of all thanks for coming although we had some problems thanks for staying one thing we are just using the whole call interface and we are happy to have call hackers like Harman Latsekow I was working on the ACPI sub system to work I was doing a lot of work on the new user space software we had really nothing to do with the kernel of the implementation we are only finding the bugs so I think I should also mention that there is an open source wiki page about the power safe project not only the power safe demon but also about all related tasks you just have to search for power safe and open source wiki and you will find it there is also a link to a power management report where we test it and present the values from the different machines we tested so you might have a look you like thanks you can tell us which brand of laptops to say more about usually the best system we had was the other system which was pretty old I guess it wasn't a new system but we were able to gain over 60% in the system especially runtime device power management was very helpful in the system because idle devices were consuming a lot of power without being used so this was also the last part when you are starting to set up special devices it's supposed that the device has to support that feature with hardware and driver dependent I guess the driver had to implement and care about saving its data and so on we also had to place an immediate laptop and there we had nearly no results of power saving with the runtime device power management because the device is hardware responsive so and everything is very experimental we also encountered a lot of crashes when using the runtime device power management because the device wasn't up again and it was being used excess from user space do you maintain a database of which devices are able to save power I mean if you have to go for an item and then you have to choose and you have to do several everything else to choose I think power management is quite a good person to choose one or another one first time that the chips are quite intelligent if they are not being used they power down a lot without anything being done from the current I think that the IPW is a good example for consumers a lot of power is needed the IPW one and a half year ago it worked perfectly and then was two weeks or a month where the current oops is why I'm saying that's because the driver is able to do that or it's because the hardware I'm not sure but I think the driver the implementation was broken at the moment but I'm really not sure about that but do you know how many other neatness devices will allow you to detect link while in power saving mode so then you can automatically power them up or down depending on whether a cable is plugged in we don't know currently I've not seen a a module or a device where you can detect the link while the device is powered down but then maybe it's done let's say I want to buy a laptop I'm going to a store with a live CD is there any way I can test that power to save features of that laptop because I don't have a multimeter present actually you are able to have a look at the power consumption using ACPI so this might be a hint if it is good or not but don't take it for sure it would make sense to have some database like when we are doing our tests and I think especially when we are talking about chips if an ethanol chip is adding a lot of power in this system it will be the same for another laptop brand same chip so this might be a hint if you have some database with the information thanks for coming