The Linaro Connect scheduler minisummit [LWN.net]

The Linaro Connect scheduler minisummit

Posted Feb 23, 2012 7:15 UTC (Thu) by dlang (guest, #313)
Parent article: The Linaro Connect scheduler minisummit

as I noted in the big.LITTLE topic, it's not just embedded/SoC systems that can use this sort of thing, current multicore monsters from Intel/AMD have some of the same design trade-offs (turbo mode where you shut some cores off to increase the speed of other cores while remaining within the same thermal envelope is one example)

I am also very curious at how well the current scheduler works on a system with significantly different CPU speeds (ignoring the question of tuning cores on and off, how well does it spread the work?, what happens with a cpu hog thread? can it get stuck on a slow core?)

to post comments

The Linaro Connect scheduler minisummit

Posted Feb 23, 2012 16:11 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (1 responses)

Indeed, this should be of general interest. If nothing else, the fact that several people outside of the ARM community showed up for the mini-summit should be strong evidence of that. ;-)

On your second question, I could give an opinion, but why not just try it on some of the current systems you mentioned?

The Linaro Connect scheduler minisummit

Posted Feb 23, 2012 19:20 UTC (Thu) by dlang (guest, #313) [Link]

> On your second question, I could give an opinion, but why not just try it on some of the current systems you mentioned?

simple, I don't happen to own any such systems :-) the ones I can freely tweak can't clock the different cores at different speeds.

The Linaro Connect scheduler minisummit

Posted Feb 24, 2012 8:39 UTC (Fri) by rvfh (guest, #31018) [Link] (2 responses)

> I am also very curious at how well the current scheduler works on a system with significantly different CPU speeds (ignoring the question of tuning cores on and off, how well does it spread the work?, what happens with a cpu hog thread? can it get stuck on a slow core?)

I am no expert but recently had a look at the CFS (completely fair scheduler) code. The CFS only considers on core, and has a load balancing mechanism which is triggered when a core becomes idle.

So if your big.LITTLE is fully busy, things will work although your high priority tasks might be on the 'wrong' core (the A7 i.o. the A15), and indeed a CPU hog thread could be stuck on the LITTLE when there is some idle time on the big.

One solution could be to automatically evaluate the performance of each core (bogomips looks like a good enough measure to me) at startup, and then decide that a thread that is CPU-starved in the LITTLE shall be moved to the big. This means changing just the load balancer.

Another approach is to assume that user-space knows better (which may well be true in some cases like video decoding and gaming) and have a daemon decide which CPU type which threads will be run on, and when to start/stop CPUs.

The Linaro Connect scheduler minisummit

Posted Feb 24, 2012 8:53 UTC (Fri) by dlang (guest, #313) [Link]

having userspace decide when to start/stop cores makes sense to me (but apparantly others disagree), but once userspace has made cores available to the system, having to have it evaluate which cores a process can run on continually seems like a bad idea.

It's common for a process that's frequently a CPU hog to have times when it's not, and in any case, having a CPU hog not running because the 'fast' cores are all busy when a 'slow' core is idle is a bad idea.

so 'fixing' this problem by relying on userspace to set/adjust affinity settings doesn't seem workable.

Different workloads will likely need different approaches

Posted Feb 24, 2012 16:39 UTC (Fri) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Indeed, I do not expect a one-size-fits-all solution to the general problem of scheduling on heterogeneous multiprocessors. In some cases, userspace will know best, but in other cases the kernel's overall view of the activities of multiple independent applications will win the day. Other cases will require cooperation between userspace and the kernel.

I do expect no shortage of challenging and interesting problems to arise in this space!