Re: [RFC 08/14] sched/tune: add detailed documentation

[Peter Zijlstra]

On Tue, Sep 15, 2015 at 04:00:45PM +0100, Patrick Bellasi wrote:

> > I'm curious about the drive for one tunable. Is that something there's
> > specifically been a broad call for? Don't get me wrong, I'm all for
> > simplification and cleanup, if the flexibility and used features can be
> > retained.
> 
> All this thread [1] was somehow calling out for a solution which goes
> in the direction of a single tunable.
> 
> The main idea is to exploit the current effort around EAS.
> While we are redesign some parts of the scheduler to be energy-ware it
> is convenient also to include in that design a knob which allows to
> configure how much we want to optimize for reduced power consumption
> or increased performance.

Please flip the argument around; providing lots of knobs for vendors to
do $magic with is _NOT_ a good thing.

The whole out-of-tree cpufreq governor hack fest Android thing is a
complete and utter fail on all levels. Its the embedded, ship, forget,
not contribute cycle all over again.

Making that harder is a _GOOD_ thing.

Esp. now that we get hardware which has multiple frequency domains on
the CPU cores, this is going to be really important.


> > Agreed it's not affecting scheduler decision making (not directly). It's
> > more just the mixing of the policy into the same code, as margin is
> > added in enqueue_task_fair()/task_tick_fair() etc. That one in
> > particular would probably be easy to solve. A more difficult one is if
> > someone wants to make adjustments to the load tracking algorithm because
> > it is driving CPU frequency.
> 
> That's not so straightforward.
> 
> We have plenty of experience, collected on the past years, on CPUFreq
> governors and customer specific mods.
> Don't you think we can exploit that experience to reason around a
> fresh new design that allows to satisfy all requirements while
> providing possibly a simpler interface?
> 
> I agree with you that all the current scenarios must be supported by
> the new proposal. We should probably start by listing them and come
> out with a set of test cases that allow to verify where we are wrt
> the state of the art.
> 
> Tools and benchmarks to verify the proposals and measure the
> regress/progress should become more and more used.
> This is an even more important requirement to setup a common
> language and aims at objective evaluations.
> Moreover, it has been already required by scheduler maintainers in the
> past.

This.

And if $vendor feels their use case doesn't perform well, have them
contribute a benchmark for it. They must have one anyway -- how else are
they going to evaluate the current cpufreq hackery?


Do not encourage vendors to add 'features' in magic warts. Strive to
improve Linux for everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/