| |||||||||||||
Linux support for ARM big.LITTLELinux support for ARM big.LITTLEPosted Feb 17, 2012 5:17 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: Linux support for ARM big.LITTLE by hamish Parent article: Linux support for ARM big.LITTLE
right, but this sort of decision is too system specific to put into the kernel. Instead you want to have a userspace daemon decide what processors to use.
If the load if heavy enough, you want to use every processing cycle you have available. If the load is a little lighter, you may turn off some of the slow cores to save power (if your "race to idle" logic applies to the use case and you really will go idle), let the load drop some more and you will want to turn on the slow cores and turn off a fast one, etc
the possible combinations are staggering, and include user policy trade-offs that can get really ugly
race-to-idle is not an absolute, it's an observation that at the current time, the power efficiency of CPUs is such that for a given core, you are more efficient to race-to-idle than to reduce your clock speed. But when you then compare separate cores with different design frequencies, the situation may be very different.
remember that you can run a LOT of low-power cores for the same power as a single high-power core, enough that if your application can be parallelized well you are far better off with 100 100MHz cores than one 1GHz core, both in the amount of power used and the amount of processing you can do.
race-to-idle also assumes that as soon as you finish the job you can shut down. This is very true in batch job situations, but most of the time you don't really go into your low-power mode immediatly, instead you run idle for a little bit, then shift to a lower power mode, wait some more, etc (and or much of this you keep the screen powered, etc), all these things need to be taken into consideration for a particular gadget when you are deciding what your best power strategy is going to be.
(Log in to post comments)
Linux support for ARM big.LITTLE Posted Feb 17, 2012 6:29 UTC (Fri) by hamish (subscriber, #6282) [Link]
It would be good to be able to have some generic logic available in the kernel - as a default, with knobs to take control from userspace if there is a policy daemon available.
Perhaps something like a blending of the scheduler with a cpu-freq governor:
Obviously, this would not suit all workloads, but would provide a good starting point and seems like it could be of use in other asymmetric scenarios.
Sure, race-to-idle is possibly only applicable to current hardware (and maybe only batch jobs), but I also think that similar principles are likely to apply to user-perceived latencies during interactive tasks - especially if you can powerdown what is likely to be a power hungry core and keep the residual activity running on the slow core.
Linux support for ARM big.LITTLE Posted Feb 17, 2012 19:09 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
in the existing scheduler, a busy core is a signal for other cores to pull load from it. Unless you have individual threads that max out the slow CPU, this should just work. This includes moving load to the slower cores.
the userspace power management daemon should look at the load and make decisions on what cores to power up/down or speed up/slow down.
Part of powering down a core is telling the system to pull all of the load from that core.
|
|||||||||||||