WEBVTT 00:00.000 --> 00:11.800 So, hello everyone, so in this talk, I will talk about tuning and building Linux for 00:11.800 --> 00:26.000 all the poor, so just, yeah, just to the tour, yeah, thank you, just a little bit about me 00:26.000 --> 00:31.360 before starting, so I'm carrying out, I'm working at Sour Fallenux since five years, and 00:31.360 --> 00:37.000 I'm really working on creating local-based distribution, kernel debugging, secure booting 00:37.000 --> 00:41.720 implementation, and creating some media application. 00:41.720 --> 00:46.400 And Sour Fallenux is working since twenty-five years in open source technologies in many 00:46.400 --> 00:53.040 ways, including industrial products where I am working. 00:53.040 --> 01:00.040 So now that the presentation now done, we can go into the subject, so poor saving has always 01:00.040 --> 01:05.040 been a major preoccupation in the number of the system, as by definition they could have 01:05.040 --> 01:18.040 some energy conflicts, and so when we go into a embedded project they are the energy saving 01:18.040 --> 01:20.880 it's in the earth of the discussions. 01:20.880 --> 01:30.880 So energy saving is always a set of compromise in terms of system or peripheral availability, 01:30.880 --> 01:33.680 time to work, etc. 01:33.680 --> 01:40.800 So in this talk, I will present you multiple ways of reducing the energy consumption of 01:40.800 --> 01:47.440 the number of these Linux, and also to illustrate a bit, I will show some measurements 01:47.440 --> 01:54.400 results we have done on the I-MX8. 01:54.400 --> 02:01.120 So of course we start with the most obvious, but also the most effective in terms of 02:01.120 --> 02:03.520 manage saving, it's the extension. 02:03.520 --> 02:10.760 So on some projects, the system does not need to be up all the time, so this is the 02:10.760 --> 02:17.760 kind of solution could be very interesting, if waiting for the device to boot is not 02:17.760 --> 02:19.760 an issue. 02:19.760 --> 02:29.520 So on the stock, on the stock, constructors BSP, on the I-MX8, we measure an average 02:29.520 --> 02:36.200 boot time of around 16 seconds between the power up of the board and system D, as rich 02:36.200 --> 02:44.120 the multi-user targets that could be considered as the end of the boot in a non-graphical 02:44.120 --> 02:45.120 system. 02:45.120 --> 02:52.440 So obviously, this system, this stock, constructors system, could be modified to reduce the 02:52.440 --> 03:01.760 time to boot, and there are multiple ways of doing it, like visible the U-BDLA, activate 03:01.760 --> 03:06.800 the U-BDLA, activate the control logs, optimize the kernel and system de-configuration, 03:06.800 --> 03:07.800 etc. 03:07.800 --> 03:15.240 But this is completely another subject, and nicely an XP has been doing an optimization 03:15.240 --> 03:25.240 study on the I-MX8, and they applied all the kind of all the optimization I just said, 03:25.240 --> 03:30.080 and they were measuring a boot time of 3.8 seconds. 03:30.080 --> 03:39.280 So even if the I-MX8 was power off, it was still consuming some currents, so it 03:39.280 --> 03:47.440 not the measure was not zero, but we could measure a current saving of around 90% between 03:47.440 --> 03:53.440 the power on system and the power off system. 03:53.440 --> 03:57.400 So now we can start into the suspend mode. 03:57.400 --> 04:02.400 So we can start with the suspend either, so what is suspend to either? 04:02.400 --> 04:11.120 A standby mode, that is purely software, and the latest version of the standby systems. 04:11.120 --> 04:19.280 So it was backed by freezing the user space, suspending all the processes, and it puts 04:19.280 --> 04:22.600 all the pair of all in standby mode. 04:22.600 --> 04:32.480 So this mode avoids going to a complete boot, so it's not a re-lunching the boot 04:32.480 --> 04:35.080 order or not re-lunching the kernel, etc. 04:35.080 --> 04:44.200 So it's quite fast to have a functional system after re-lunching it. 04:44.200 --> 04:51.920 So in this mode, the stock is still alimentated, but on a very low workload, so it reduces 04:51.960 --> 04:55.560 the consumption, the global consumption. 04:55.560 --> 05:05.840 So on the I-MX8, the kernel was measuring a wake-up time of 0.77 seconds, and the consumption, 05:05.840 --> 05:17.400 we measure a consumption of 12.5% less compared to a power on system. 05:17.400 --> 05:21.400 Next standby mode is the suspend to run. 05:21.400 --> 05:27.640 So the suspend to run is a standby mode that saves the system state, so the CPU state, 05:27.640 --> 05:30.840 the memory state, etc. in the run. 05:30.840 --> 05:36.640 And the wall system, the CPU, the pair of all the boosts, except of course the run, is 05:36.640 --> 05:46.840 put in a standby mode, and low consumption, but same as for the suspend to idle mode, 05:46.840 --> 05:56.280 the user space is freed, and it avoids re-lunching the boot order, the kernel and system. 05:56.280 --> 06:04.600 And the wake-up could be controlled via a pair of all, like a silicon sole, a GPU, or a 06:04.600 --> 06:07.760 co-processor, for example. 06:07.760 --> 06:13.800 And after the wake-up has been triggered, triggered on the I-MX8, the kernel was measuring 06:13.880 --> 06:19.240 around 0.7 seconds or so of a wake-up time. 06:19.240 --> 06:26.240 And for this mode, the consumption was reduced by 50% compared to a full power on system, 06:26.240 --> 06:29.520 so quite efficient. 06:29.520 --> 06:34.240 And the last suspend mode is the suspend to disk. 06:34.240 --> 06:42.440 So this is quite similar as the suspend to run, so it saves the system state, instead 06:42.440 --> 06:48.480 of saving it in the run, it saves it in the disk, so on a EMFC, for example. 06:48.480 --> 06:56.360 And except for certain pair of all that remains standby mode, all the pair of all are 06:56.360 --> 06:59.480 a power off, including the run. 06:59.480 --> 07:07.120 So this mode is very close to a complete shutdown. 07:07.160 --> 07:16.200 So the drawback of this mode is that it requires the boot loader to be launched, so that 07:16.200 --> 07:29.280 there is a French instance of the kernel to restore the system that was before the E-Bernation. 07:29.280 --> 07:37.320 So when we used the optimization with some optimization, we measured the wake-up time 07:37.320 --> 07:51.680 of the consumption was quite similar, and we were reaching a reduction by 90% or so. 07:51.680 --> 08:00.760 So as suspend mode, our powering of all the devices, the wake-up time is very, very 08:00.760 --> 08:05.600 influenced by the number of devices that are enabled. 08:05.600 --> 08:12.880 Since Linux requires to power up all the device, the fewer you have a device enabled, 08:12.880 --> 08:19.920 and the shorter the time it takes to have a full power on system. 08:19.920 --> 08:29.360 For example, we did the measure by deactivating the USB on the suspend to run mode, and 08:29.360 --> 08:38.760 we reduced the wake-up time to 0.05 seconds instead of 0.07 seconds. 08:38.760 --> 08:46.040 So here is a little board to summarize the measures. 08:46.040 --> 08:54.200 So of course the solution you will implement or choose will be depending on your product 08:54.200 --> 09:01.880 context, and of course the measurements we have seen in the iMixet we will of course be 09:01.880 --> 09:11.400 different in all the board because that's not the same hardware as not the same drivers. 09:11.400 --> 09:23.240 Now that we have seen the complete shutdown or the system, and on some product we can 09:23.240 --> 09:32.160 do that because we need to receive messages within the short time or something like that. 09:32.160 --> 09:39.880 The first study you can make is to reduce the consumption by turn down some devices directly 09:39.960 --> 09:44.280 at the time if you don't need them. 09:44.280 --> 09:50.200 But there is another solution, so we saw that we have suspend modes for the world system, 09:50.200 --> 09:56.280 but we have suspend modes for all some peripherals. 09:56.280 --> 10:08.080 Not all peripherals are not all peripherals are super-technique, but some are super-technique. 10:08.080 --> 10:20.920 So as on some various products, all the peripherals are not required at every time, we 10:20.920 --> 10:29.760 could disable some peripherals when we are not needed. 10:29.840 --> 10:39.440 So for example, we have done measurements on the USB stack, so the kernel on the USB stack 10:39.440 --> 10:46.320 is not activating the dynamic management of the alimentation by default. 10:46.320 --> 10:58.040 You have to enable it by using auto in the power control C surface file, and the USB specification, 10:58.120 --> 11:06.320 normally it is specified that all USB devices could be or should support the power management, 11:06.320 --> 11:16.120 but the fact is that some are a good number of USB devices, have some problems 11:16.120 --> 11:24.480 super-technique, there is no issue to put them in suspend mode, but the problem is when 11:24.560 --> 11:30.280 we resume them, they don't come back or other things. 11:30.280 --> 11:35.200 So that's why the kernel is not activating by default. 11:35.200 --> 11:44.880 So to illustrate it, we move to a dynamic management of the alimentation on the USB 56% 11:44.880 --> 11:52.040 sorry, of compare when the USB modem was poor on, so that's quite efficient when you don't 11:52.040 --> 11:59.040 need this USB modation in terms of energy saving. 11:59.040 --> 12:08.600 Also, the connectivity devices are very, very poor consuming, to save some power, it is recommended 12:08.600 --> 12:17.600 to disable them when they are needed, and it is also worse to send both of that to minimize 12:17.680 --> 12:31.320 the times they are enabled, and if you enable them each time you have a short amount of data 12:31.320 --> 12:40.000 to send, it's not quite efficient, but it depends on the product context, of course. 12:40.000 --> 12:49.400 For example, we disable the Wi-Fi, the Ethernet, and the modem by using these common lines 12:49.400 --> 13:04.000 tools, and we were reaching a reduction of 52% compared when they were all poor on. 13:04.000 --> 13:17.920 So last optimization that I will present in this talk will be CPU Freck, so if you have 13:17.920 --> 13:26.000 high level of CPU consumption, it could be very interesting to reduce the CPU frequency, 13:26.240 --> 13:33.920 and this we only have an impact if your CPU is CPU low this high, because if the CPU 13:33.920 --> 13:38.760 low this value low, it doesn't really have an impact. 13:38.760 --> 13:44.900 So here are the CPU Freck configuration that are available, so the first is the CPU 13:44.980 --> 13:54.740 effect on the ones, that's controlled the processor frequency, according to the current system 13:54.740 --> 14:05.100 load, so it just checked the CPU usage, and according to it it changed the CPU frequency, 14:05.100 --> 14:13.180 this could be very quickly the CPU frequency, and that's why there is the conservative 14:13.260 --> 14:21.620 CPU governance, that is quite like on the moon, but it's moving more gracefully, the frequency 14:21.620 --> 14:29.140 and does not go to the maximum frequency as soon as there is some load on the CPU, and 14:29.140 --> 14:41.140 there the poor save performance governance that are static, static frequency, so the poor 14:41.140 --> 14:45.220 save is set at the lowest frequency and the performance at the highest frequency possible 14:45.220 --> 14:53.140 in the limit of course, and after that there is the user space that's allowed to put the frequency 14:53.140 --> 15:05.940 you once on the limits in the file, so you need to be able to change that, and the last one 15:06.020 --> 15:16.020 is the schedule to one, it's changing the frequency, and we see the schedule, instead of the 15:16.020 --> 15:26.740 an average of the load on the CPU, so what was the impact of this CPU frequency, so we 15:26.820 --> 15:37.300 measure firstly, when there was zero or 10% of CPU consumption, and moving to the minimum 15:37.300 --> 15:45.860 or maximum frequency, it was quite similar in terms of poor consumption, and we measure it 15:45.860 --> 15:56.100 at 100% of CPU load, and there was an improvement here, so we reduce the energy consumption 15:56.100 --> 16:04.180 by 23% between the the the the minimum frequency and the maximum frequency in terms of CPU, 16:04.180 --> 16:15.780 so that has an impact, but of course only when there is a high level of CPU, so to conclude 16:15.780 --> 16:23.460 as you understand poor saving is highly dependent on your 40 context, and there is also 16:23.460 --> 16:32.020 other optimization that exists, but when not have the time to present them poor, and also 16:33.060 --> 16:40.580 a quick reminder that all the the the values that are presented here are on the iMIX states, 16:40.580 --> 16:48.020 of course the the values would would change between the hardware, and also by default, the 16:48.900 --> 16:56.020 constructor bsp are not all implemented, for example, the suspend modes, by default, so 16:56.020 --> 17:00.900 maybe it will require some some customization on your distribution by your own. 17:02.740 --> 17:03.940 Thank you very much.