All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Muckle <steve.muckle@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>,
	Patrick Bellasi <patrick.bellasi@arm.com>
Cc: 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: Tue, 15 Sep 2015 17:34:29 -0700	[thread overview]
Message-ID: <55F8B915.30202@linaro.org> (raw)
In-Reply-To: <20150915151953.GF16853@twins.programming.kicks-ass.net>

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?

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?

cheers,
Steve

  reply	other threads:[~2015-09-16  0:34 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 [this message]
2015-09-16  7:47                   ` Ingo Molnar
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=55F8B915.30202@linaro.org \
    --to=steve.muckle@linaro.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.