Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1225313

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

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [RFC 08/14] sched/tune: add detailed documentation
Date 2015-09-15 17:30 +0200
Message-ID <q90le-mc-55@gated-at.bofh.it> (permalink)
References (2 earlier) <q4yQy-7Gl-7@gated-at.bofh.it> <q6U0y-56Z-21@gated-at.bofh.it> <q7ux4-8mN-9@gated-at.bofh.it> <q8IeC-89j-21@gated-at.bofh.it> <q901Q-8qX-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC 08/14] sched/tune: add detailed documentation Steve Muckle <steve.muckle@linaro.org> - 2015-09-09 22:20 +0200
  Re: [RFC 08/14] sched/tune: add detailed documentation Patrick Bellasi <patrick.bellasi@arm.com> - 2015-09-11 13:20 +0200
    Re: [RFC 08/14] sched/tune: add detailed documentation Steve Muckle <steve.muckle@linaro.org> - 2015-09-14 22:10 +0200
      Re: [RFC 08/14] sched/tune: add detailed documentation Patrick Bellasi <patrick.bellasi@arm.com> - 2015-09-15 17:10 +0200
        Re: [RFC 08/14] sched/tune: add detailed documentation Peter Zijlstra <peterz@infradead.org> - 2015-09-15 17:30 +0200
          Re: [RFC 08/14] sched/tune: add detailed documentation Steve Muckle <steve.muckle@linaro.org> - 2015-09-16 02:40 +0200
            Re: [RFC 08/14] sched/tune: add detailed documentation Ingo Molnar <mingo@kernel.org> - 2015-09-16 09:50 +0200
        Re: [RFC 08/14] sched/tune: add detailed documentation Steve Muckle <steve.muckle@linaro.org> - 2015-09-16 02:00 +0200
          Re: [RFC 08/14] sched/tune: add detailed documentation Juri Lelli <juri.lelli@arm.com> - 2015-09-16 11:30 +0200
            Re: [RFC 08/14] sched/tune: add detailed documentation Vincent Guittot <vincent.guittot@linaro.org> - 2015-09-16 15:50 +0200
          Re: [RFC 08/14] sched/tune: add detailed documentation Patrick Bellasi <patrick.bellasi@arm.com> - 2015-09-16 12:10 +0200

csiph-web