linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>,
	Ingo Molnar <mingo@elte.hu>,
	Russell King <linux@arm.linux.org.uk>,
	Oleg Nesterov <oleg@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Nicolas Pitre <nico@fluxnic.net>, Mike Chan <mike@android.com>,
	Todd Poynor <toddpoynor@google.com>,
	cpufreq@vger.kernel.org, kernel-team@android.com,
	linaro-kernel@lists.linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Arjan Van De Ven <arjan@infradead.org>
Subject: Re: [PATCH RFC 0/4] Scheduler idle notifiers and users
Date: Wed, 8 Feb 2012 15:23:15 -0500	[thread overview]
Message-ID: <20120208202314.GA28290@redhat.com> (raw)
In-Reply-To: <1328670355.2482.68.camel@laptop>

On Wed, Feb 08, 2012 at 04:05:55AM +0100, Peter Zijlstra wrote:
 
 > Argh, no.. cpufreq so sucks rocks. Can we please just scrap it and write
 > an entirely new infrastructure that is much more connected to the
 > scheduler and do away with this stupid need to set P-states from a
 > schedulable context.

Well there's bits of it that will live on regardless of implementation
(The lower level drivers are pretty much necessary). But all the rest..

If the new scheduler bits grew a per-task proc file for their power saving
policy (powersave/performance/scale on-demand), and a sysfs knob to set
the default policy, then I think a lot of the horrors in ondemand.c etc
could just go away.

Some of what the existing governors do would need reimplementing, but the
scheduler has the smarts to make the right decisions anyway.

The midlayer glue (cpufreq.c) could mostly go away, along with as many
of the user-facing knobs as possible.

I think the biggest mistake we ever made with cpufreq was making it
so configurable. If we redesign it, just say no to plugin governors, and
yes to a lot fewer sysfs knobs.

So, provide mechanism to kill off all the governors, and there's a
migration path from what we have now to something that just works
in a lot more cases, while remaining configurable enough for the corner-cases.

	Dave


  reply	other threads:[~2012-02-08 20:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08  1:39 [PATCH RFC 0/4] Scheduler idle notifiers and users Anton Vorontsov
2012-02-08  1:41 ` [PATCH 1/4] sched: Introduce idle notifiers API Anton Vorontsov
2012-02-08  1:43 ` [PATCH 2/4] sched: Wire up idle notifiers Anton Vorontsov
2012-02-08  1:44 ` [PATCH 3/4] cpufreq: New 'interactive' governor Anton Vorontsov
2012-02-08 23:00   ` Vincent Guittot
2012-02-09  0:32     ` Anton Vorontsov
2012-02-08  1:44 ` [PATCH 4/4] ARM: Move leds idle start/stop calls to sched idle notifiers Anton Vorontsov
2012-02-08  3:05 ` [PATCH RFC 0/4] Scheduler idle notifiers and users Peter Zijlstra
2012-02-08 20:23   ` Dave Jones [this message]
2012-02-08 21:33     ` Benjamin Herrenschmidt
2012-02-09  7:51       ` Ingo Molnar
2012-02-11  3:15         ` Saravana Kannan
2012-02-11 14:39           ` Mark Brown
2012-02-11 14:53             ` Peter Zijlstra
2012-02-11 15:33               ` Mark Brown
2012-02-15 13:38                 ` Peter Zijlstra
2012-02-15 16:04                   ` Mark Brown
2012-02-12 21:33               ` Benjamin Herrenschmidt
2012-02-11 14:45           ` Ingo Molnar
2012-02-14 23:20             ` Saravana Kannan
2012-02-15 13:38               ` Peter Zijlstra
2012-02-15 14:02                 ` Russell King - ARM Linux
2012-02-15 15:01                   ` Peter Zijlstra
2012-02-15 16:00                     ` Russell King - ARM Linux
2012-02-15 16:09                       ` Peter Zijlstra
2012-02-16  3:31                     ` Benjamin Herrenschmidt
2012-02-16 10:14                       ` Peter Zijlstra
2012-02-17  9:00                     ` Dominik Brodowski
2012-02-20 11:03                       ` Peter Zijlstra
2012-02-21 12:38                     ` Pantelis Antoniou
2012-02-21 12:56                       ` Peter Zijlstra
2012-02-21 13:31                         ` Pantelis Antoniou
2012-02-21 14:52                           ` Amit Kucheria
2012-02-21 17:06                             ` Pantelis Antoniou

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=20120208202314.GA28290@redhat.com \
    --to=davej@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=anton.vorontsov@linaro.org \
    --cc=arjan@infradead.org \
    --cc=benh@kernel.crashing.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=kernel-team@android.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mike@android.com \
    --cc=mingo@elte.hu \
    --cc=nico@fluxnic.net \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=toddpoynor@google.com \
    /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).