From: Ingo Molnar <mingo@kernel.org>
To: Steve Muckle <steve.muckle@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Patrick Bellasi <patrick.bellasi@arm.com>,
Ricky Liang <jcliang@chromium.org>,
Ingo Molnar <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [RFC 08/14] sched/tune: add detailed documentation
Date: Wed, 16 Sep 2015 09:47:24 +0200 [thread overview]
Message-ID: <20150916074724.GB27378@gmail.com> (raw)
In-Reply-To: <55F8B915.30202@linaro.org>
* Steve Muckle <steve.muckle@linaro.org> wrote:
> On 09/15/2015 08:19 AM, Peter Zijlstra wrote:
> > 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.
>
> I get why the plugin-like governor interface may encourage out of tree
> development, but why would providing lots of policy knobs/tunables from
> the scheduler be bad?
There's many disadvantages:
- People/vendors learn to rely on their knob based hacks and start making noise
if one of the knobs changes or goes away, reporting regressions, not always
reporting that they have tunables twiddled.
- If distros start using knobs it's easy to get into a situation where different
distros have different knobs, and people tune them further. For every single
bugreport we'd have to first make 100% sure what the knobs are.
- Workloads can sometimes be improved by twiddling knobs - while breaking lots of
other workloads. We'd like people who contribute to the scheduler to think
about the hard problems and improve the whole picture, not just a small part of
it. There's a rich set of 'knobs' to prevent the scheduler from doing things
(the various resource affinity system calls and facilities), so it's not like
user-space does not have the flexibility.
- Having too much configuration space makes upgrades to newer kernels generally
harder - and we want to have the opposite effects.
> Shouldn't that hopefully reduce the likelihood that someone feels the need to
> roll their own stack of kernel modifications which never make it upstream?
If a scheduler bug or inefficiency can be kludged around with a knob then that
reduces the likelihood of the scheduler getting improved.
Otherwise I'd like to encourage people to change the source if they want to debug
a problem or improve things - so having to roll your own patches isn't an
unconditional negative - it's what this whole OSS thing is about.
Thanks,
Ingo
next prev parent reply other threads:[~2015-09-16 7:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 18:47 [RFC PATCH 00/14] sched: Central, scheduler-driven, power-perfomance control Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 01/14] sched/cpufreq_sched: use static key for cpu frequency selection Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 02/14] sched/fair: add triggers for OPP change requests Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 03/14] sched/{core,fair}: trigger OPP change request on fork() Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 04/14] sched/{fair,cpufreq_sched}: add reset_capacity interface Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 05/14] sched/fair: jump to max OPP when crossing UP threshold Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 06/14] sched/cpufreq_sched: modify pcpu_capacity handling Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 07/14] sched/fair: cpufreq_sched triggers for load balancing Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 08/14] sched/tune: add detailed documentation Patrick Bellasi
2015-09-02 6:49 ` [RFC,08/14] " Ricky Liang
2015-09-03 9:18 ` [RFC 08/14] " Patrick Bellasi
2015-09-04 7:59 ` Ricky Liang
2015-09-09 20:16 ` Steve Muckle
2015-09-11 11:09 ` Patrick Bellasi
2015-09-14 20:00 ` Steve Muckle
2015-09-15 15:00 ` Patrick Bellasi
2015-09-15 15:19 ` Peter Zijlstra
2015-09-16 0:34 ` Steve Muckle
2015-09-16 7:47 ` Ingo Molnar [this message]
2015-09-15 23:55 ` Steve Muckle
2015-09-16 9:26 ` Juri Lelli
2015-09-16 13:49 ` Vincent Guittot
2015-09-16 10:03 ` Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 09/14] sched/tune: add sysctl interface to define a boost value Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 10/14] sched/fair: add function to convert boost value into "margin" Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 11/14] sched/fair: add boosted CPU usage Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 12/14] sched/tune: add initial support for CGroups based boosting Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 13/14] sched/tune: compute and keep track of per CPU boost value Patrick Bellasi
2015-08-19 18:47 ` [RFC PATCH 14/14] sched/{fair,tune}: track RUNNABLE tasks impact on " Patrick Bellasi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150916074724.GB27378@gmail.com \
--to=mingo@kernel.org \
--cc=corbet@lwn.net \
--cc=jcliang@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=steve.muckle@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).