So, hello everyone, so in this talk, I will talk about tuning and building Linux for
all the poor, so just, yeah, just to the tour, yeah, thank you, just a little bit about me
before starting, so I'm carrying out, I'm working at Sour Fallenux since five years, and
I'm really working on creating local-based distribution, kernel debugging, secure booting
implementation, and creating some media application.
And Sour Fallenux is working since twenty-five years in open source technologies in many
ways, including industrial products where I am working.
So now that the presentation now done, we can go into the subject, so poor saving has always
been a major preoccupation in the number of the system, as by definition they could have
some energy conflicts, and so when we go into a embedded project they are the energy saving
it's in the earth of the discussions.
So energy saving is always a set of compromise in terms of system or peripheral availability,
time to work, etc.
So in this talk, I will present you multiple ways of reducing the energy consumption of
the number of these Linux, and also to illustrate a bit, I will show some measurements
results we have done on the I-MX8.
So of course we start with the most obvious, but also the most effective in terms of
manage saving, it's the extension.
So on some projects, the system does not need to be up all the time, so this is the
kind of solution could be very interesting, if waiting for the device to boot is not
an issue.
So on the stock, on the stock, constructors BSP, on the I-MX8, we measure an average
boot time of around 16 seconds between the power up of the board and system D, as rich
the multi-user targets that could be considered as the end of the boot in a non-graphical
system.
So obviously, this system, this stock, constructors system, could be modified to reduce the
time to boot, and there are multiple ways of doing it, like visible the U-BDLA, activate
the U-BDLA, activate the control logs, optimize the kernel and system de-configuration,
etc.
But this is completely another subject, and nicely an XP has been doing an optimization
study on the I-MX8, and they applied all the kind of all the optimization I just said,
and they were measuring a boot time of 3.8 seconds.
So even if the I-MX8 was power off, it was still consuming some currents, so it
not the measure was not zero, but we could measure a current saving of around 90% between
the power on system and the power off system.
So now we can start into the suspend mode.
So we can start with the suspend either, so what is suspend to either?
A standby mode, that is purely software, and the latest version of the standby systems.
So it was backed by freezing the user space, suspending all the processes, and it puts
all the pair of all in standby mode.
So this mode avoids going to a complete boot, so it's not a re-lunching the boot
order or not re-lunching the kernel, etc.
So it's quite fast to have a functional system after re-lunching it.
So in this mode, the stock is still alimentated, but on a very low workload, so it reduces
the consumption, the global consumption.
So on the I-MX8, the kernel was measuring a wake-up time of 0.77 seconds, and the consumption,
we measure a consumption of 12.5% less compared to a power on system.
Next standby mode is the suspend to run.
So the suspend to run is a standby mode that saves the system state, so the CPU state,
the memory state, etc. in the run.
And the wall system, the CPU, the pair of all the boosts, except of course the run, is
put in a standby mode, and low consumption, but same as for the suspend to idle mode,
the user space is freed, and it avoids re-lunching the boot order, the kernel and system.
And the wake-up could be controlled via a pair of all, like a silicon sole, a GPU, or a
co-processor, for example.
And after the wake-up has been triggered, triggered on the I-MX8, the kernel was measuring
around 0.7 seconds or so of a wake-up time.
And for this mode, the consumption was reduced by 50% compared to a full power on system,
so quite efficient.
And the last suspend mode is the suspend to disk.
So this is quite similar as the suspend to run, so it saves the system state, instead
of saving it in the run, it saves it in the disk, so on a EMFC, for example.
And except for certain pair of all that remains standby mode, all the pair of all are
a power off, including the run.
So this mode is very close to a complete shutdown.
So the drawback of this mode is that it requires the boot loader to be launched, so that
there is a French instance of the kernel to restore the system that was before the E-Bernation.
So when we used the optimization with some optimization, we measured the wake-up time
of the consumption was quite similar, and we were reaching a reduction by 90% or so.
So as suspend mode, our powering of all the devices, the wake-up time is very, very
influenced by the number of devices that are enabled.
Since Linux requires to power up all the device, the fewer you have a device enabled,
and the shorter the time it takes to have a full power on system.
For example, we did the measure by deactivating the USB on the suspend to run mode, and
we reduced the wake-up time to 0.05 seconds instead of 0.07 seconds.
So here is a little board to summarize the measures.
So of course the solution you will implement or choose will be depending on your product
context, and of course the measurements we have seen in the iMixet we will of course be
different in all the board because that's not the same hardware as not the same drivers.
Now that we have seen the complete shutdown or the system, and on some product we can
do that because we need to receive messages within the short time or something like that.
The first study you can make is to reduce the consumption by turn down some devices directly
at the time if you don't need them.
But there is another solution, so we saw that we have suspend modes for the world system,
but we have suspend modes for all some peripherals.
Not all peripherals are not all peripherals are super-technique, but some are super-technique.
So as on some various products, all the peripherals are not required at every time, we
could disable some peripherals when we are not needed.
So for example, we have done measurements on the USB stack, so the kernel on the USB stack
is not activating the dynamic management of the alimentation by default.
You have to enable it by using auto in the power control C surface file, and the USB specification,
normally it is specified that all USB devices could be or should support the power management,
but the fact is that some are a good number of USB devices, have some problems
super-technique, there is no issue to put them in suspend mode, but the problem is when
we resume them, they don't come back or other things.
So that's why the kernel is not activating by default.
So to illustrate it, we move to a dynamic management of the alimentation on the USB 56%
sorry, of compare when the USB modem was poor on, so that's quite efficient when you don't
need this USB modation in terms of energy saving.
Also, the connectivity devices are very, very poor consuming, to save some power, it is recommended
to disable them when they are needed, and it is also worse to send both of that to minimize
the times they are enabled, and if you enable them each time you have a short amount of data
to send, it's not quite efficient, but it depends on the product context, of course.
For example, we disable the Wi-Fi, the Ethernet, and the modem by using these common lines
tools, and we were reaching a reduction of 52% compared when they were all poor on.
So last optimization that I will present in this talk will be CPU Freck, so if you have
high level of CPU consumption, it could be very interesting to reduce the CPU frequency,
and this we only have an impact if your CPU is CPU low this high, because if the CPU
low this value low, it doesn't really have an impact.
So here are the CPU Freck configuration that are available, so the first is the CPU
effect on the ones, that's controlled the processor frequency, according to the current system
load, so it just checked the CPU usage, and according to it it changed the CPU frequency,
this could be very quickly the CPU frequency, and that's why there is the conservative
CPU governance, that is quite like on the moon, but it's moving more gracefully, the frequency
and does not go to the maximum frequency as soon as there is some load on the CPU, and
there the poor save performance governance that are static, static frequency, so the poor
save is set at the lowest frequency and the performance at the highest frequency possible
in the limit of course, and after that there is the user space that's allowed to put the frequency
you once on the limits in the file, so you need to be able to change that, and the last one
is the schedule to one, it's changing the frequency, and we see the schedule, instead of the
an average of the load on the CPU, so what was the impact of this CPU frequency, so we
measure firstly, when there was zero or 10% of CPU consumption, and moving to the minimum
or maximum frequency, it was quite similar in terms of poor consumption, and we measure it
at 100% of CPU load, and there was an improvement here, so we reduce the energy consumption
by 23% between the the the the minimum frequency and the maximum frequency in terms of CPU,
so that has an impact, but of course only when there is a high level of CPU, so to conclude
as you understand poor saving is highly dependent on your 40 context, and there is also
other optimization that exists, but when not have the time to present them poor, and also
a quick reminder that all the the the values that are presented here are on the iMIX states,
of course the the values would would change between the hardware, and also by default, the
constructor bsp are not all implemented, for example, the suspend modes, by default, so
maybe it will require some some customization on your distribution by your own.
Thank you very much.