| |||||||||||||
Linux support for ARM big.LITTLELinux support for ARM big.LITTLEPosted Feb 16, 2012 13:39 UTC (Thu) by const-g (subscriber, #5006)Parent article: Linux support for ARM big.LITTLE
KISS principle should apply here.
Let us consider:
(Log in to post comments)
Linux support for ARM big.LITTLE Posted Feb 16, 2012 19:09 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I think you are still adding unneded complexity.
if you have all the CPUs running, why do you care which CPU is running which process? The only reason to care would be if a process can't get it's work done on the slow CPU, and the answer to that is to have the scheduler consider this when re-balancing jobs between CPUs
Similar statements can be made about interrupt handling. If both types of CPU can handle the interrupt, why do you care which one does it?
Userspace can then control what CPUs are running, and if needed, can set affinity masks for interrupts and processes that it determines "need" to avoid the slow processors, but I really think that a slightly smarter rebalancing algorithm is the right answer in just about all cases.
the rebalancing algorithm should already be looking at more than just the number of processes, it should be looking at how much time those processes are using, and it should be considering NUMA considerations as well. If you have two cores, one slow and one fast, both running the same load, the slow one will have a much higher utilization than the fast one, and so the fast one should end up pulling work from the slow one with the existing algorithm.
There is one factor (which shows up in two aspects) that the current scheduler doesn't consider, which is the relative speed of the cores
when pulling work to the slow cpu, it assumes that if it can run on the current cpu it can run on the new cpu, this needs a scaling check
if the process is using 100% of a current cpu, it's not considered for being pulled to a new cpu on the assumption that it won't gain anything, this needs a scaling check to see if the new CPU is faster
this is all 'slow path' checks in the scheduler rebalancing code, so it shouldn't be too bad.
And as noted elsewhere, this is needed for current x86 multi-core systems because they can run different cores at different speeds.
Linux support for ARM big.LITTLE Posted Feb 16, 2012 21:45 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I guess I'm saying that it doesn't seem as if the long-term scheduler changes are very significant, and as such I don't see a lot of value in producing such a short-term hack to deal with the issue.
especially as the long term fix is needed to deal with shipping Intel/AMD x86 systems
Linux support for ARM big.LITTLE Posted Feb 17, 2012 5:06 UTC (Fri) by hamish (subscriber, #6282) [Link]
This (very appealing) simplification doesn't take into account the race to completion - so you might end up using more total power staying on the slow cpu than would have been used up by bouncing the process to the fast cpu.
I suppose a large part of this depends on the power usage profile of the two speed cpu's - if the power used by the slow cpu running at full speed is the same or less than the power used by the fast cpu (when the fast cpu is at a cpu freq that produces equivalent numbers of MIPS) then this pattern could be used.
There still would need to be some way to work out that a process could benefit from a lower latency - and allow it to use the higher speeds available on the fast cpu.
Linux support for ARM big.LITTLE Posted Feb 17, 2012 5:17 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
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.
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.
|
|||||||||||||