Plumbers: Tweaking scheduler policy micro-conf RFP

[Peter Zijlstra]

On Fri, 2012-05-18 at 17:18 +0100, Morten Rasmussen wrote:

> > one knob: sched_balance_policy with tri-state {performance, power, auto}
> 
> Interesting. What would the power policy look like? Would performance
> and power be the two extremes of the power/performance trade-off? 

Performance is basically what we do now, power I'll leave up to whomever
wants to implement it. My only concern is that the code is pretty and I
can actually understand it.

Well, and that 'everybody' can agree on it :-)

One thing to keep in mind though is that the goal shouldn't be to make
it the best power aware scheduler for your platform of interest but to
make a reasonably coherent framework that provides sufficient power
awareness for all our platforms.

I much prefer simplicity and robustness over the last 10% at this point.

> In that case I would assume that most embedded systems would be using auto.

Ah, I think you mis-understand auto, that would just be a binary flip
between either based on external data. Like if you're on AC you pick
performance, if you're on battery you pick power.

> > The 'performance' policy is typically to spread over shared resources so
> > as to minimize contention on these.
> >
> 
> Would it be worth extending this architecture specification to contain
> more information like CPU_POWER for each core? 

Yes, currently we assume all logical cpus are equal (with a small
exception for SMT).

> After having experimented
> a bit with scheduling on big.LITTLE my experience is that more
> information about the platform is needed to make proper scheduling
> decisions. So if the topology definition is going to be more generic and
> be set up by the architecture it could be worth adding all the bits of
> information that the scheduler would need to that data structure.

Agreed, although we should strive to minimize the set. And we should
make all interfaces optional, so that if an architecture doesn't use it
it'll go with the defaults.

> With such data structure, the scheduler would only need one knob to
> adjust the power/performance trade-off. Any thoughts?

That's the plan.

> > To over-ride the defaults. But ideally I'd leave those until after we've
> > got the basics working and there is a clear need for them (with a
> > spread/pack default for perf/power aware).
> 
> In my experience power optimized scheduling is quite tricky, especially
> if you still want some level of performance. For heterogeneous
> architecture packing might not be the best solution. Some indication of
> the power/performance profile of each core could be useful.

Right, hence my suggestion to add possible hints to over-ride the
default policies.

But also the desire to only add them once the 'regular'/'simple' bits
work properly.