Using Info from User Space? [LWN.net]

Using Info from User Space?

Posted Nov 2, 2013 20:06 UTC (Sat) by roblucid (guest, #48964)
Parent article: The power-aware scheduling mini-summit

Wether to run things power economically, or prioritise performance, seems like something only user space can know to me. Why run multiple cores in a race to idle on nice-ed jobs, which by definition are lo priority?

Again, it´d be nice for a user to choose between saving watts or time to, starting up extra cores on processing or wake ups, seems bit extravagent on hyper-threaded or FP sharing AMD modules, simply for small increases on idle time. Yet I can see benchmarks or some work loads, would depend on rapid reaction to increasing work load, without policy hints from User Space how can the scheduler to the right thing?

to post comments

Using Info from User Space?

Posted Nov 2, 2013 21:09 UTC (Sat) by raven667 (guest, #5198) [Link] (4 responses)

The amount of work which needs to be done doesn't change and is determined by the user, the kernel should have the latitude to schedule the work it's been asked to do in the most efficient manner.

Using Info from User Space?

Posted Nov 3, 2013 5:09 UTC (Sun) by dlang (guest, #313) [Link] (3 responses)

which is better, powering two cores that share cache and cause the process to take 10% longer to run, or powering two cores that don't share cache that finish faster, but take 20% more power to run? (picking number out of thin air to represent a real tradeoff)

the kernel can't know if the user would rather finish faster at the cost of more power or to save power even if it takes longer to finish unless the user tells the kernel somehow, so it's not just as simple as 'userspace determines the work to be done and the kernel schedules it in the most efficient manner' because 'most efficient' is not a well defined term.

The other issue is that the user may want the system to remain at higher speeds even when idle to reduce the latency when new work arrives.

Using Info from User Space?

Posted Nov 3, 2013 15:14 UTC (Sun) by raven667 (guest, #5198) [Link] (2 responses)

I think that the point is that the tradeoff is usually the path which finishes faster is also the path which uses the least power, because the system can stop using power as soon as it finishes its work so faster is better, from a power management perspective. So the trade off is that you can power two cores and take 10% longer, or power up four cores, use higher power in the short term, finish fast, then shut them all off and save power.

Using Info from User Space?

Posted Nov 3, 2013 15:23 UTC (Sun) by raven667 (guest, #5198) [Link]

I am also going to add that latency is a big part of this calculation. As you correctly point out, keeping the processing core hotted up reduces latency for new work that is unknown to the scheduler. The finish fast theory is all about latency too, what is the latency of powering up more cores to add capacity versus just running on the cores which are already active, which way will finish first and return to a lower power state the fastest. The schedule can guesstimate this for work it knows about, although interrupt driven work has different properties.

Using Info from User Space?

Posted Nov 3, 2013 16:58 UTC (Sun) by dlang (guest, #313) [Link]

It's not as simple as you are painting it.

it's not just the cores that need to be powered, it's the cache and other aspects of the chip.

it's not powering up two cores to get it done, or four cores to get it done in half the time.

it's powering up two cores and one set of cache, or powering up two cores and two sets of cache to get done 10% faster

from a strict power budget, powering one set of cache and taking 10% longer is probably a win, but is the user willing to sacrifice the performance?

and there are also secondary effects, the speed that you have the CPU set to run may impact the video performance, and if you have the user running something very demanding on the GPU, should you slow down the CPU (and therefor the GPU) to save power or not?

these are decisions that the kernel cannot make on it's own, because it doesn't know the user's priorities.