From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: Matthew Garrett <mjg@redhat.com>
Cc: Corrado Zoccolo <czoccolo@gmail.com>,
Dave Jones <davej@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: ondemand: Introduces stepped frequency increase
Date: Wed, 08 Jul 2009 09:33:14 -0700 [thread overview]
Message-ID: <1247070794.11545.123.camel@localhost.localdomain> (raw)
In-Reply-To: <20090708161052.GA20951@srcf.ucam.org>
On Wed, 2009-07-08 at 09:10 -0700, Matthew Garrett wrote:
> On Wed, Jul 08, 2009 at 03:56:33PM +0200, Corrado Zoccolo wrote:
> > The patch introduces a new sysfs tunable cpufreq/ondemand/freq_step,
> > as found in conservative governor, to chose the frequency increase step,
> > expressed as percentage (default = 100 is previous behaviour).
> >
> > This allows fine tuning powersaving on mobile CPUs, since smaller steps will allow to:
> > * absorb punctual load spikes
> > * stabilize at the needed frequency, without passing for more power consuming states, and
>
> Is this a measured powersaving? The ondemand model is based on the
> assumption that the idle state is disproportionately lower in power than
> any running state, and therefore it's more sensible to run flat out for
> short periods of time than run at half speed for longer. Is this
> inherently flawed, or is it an artifact of differences in your processor
> design?
>
As Matthew mentioned, ondemand governor wants to run at highest speed
and get to idle sooner. Another aspect of ondemand governor is to have
very low response time for freq increase on sudden increase in load.
With freq_step, it may take long time before we can respond to sudden
increase of load from idle to full busy.
Even though you have default step as 100, as soon as we have this
variable, there will be users/distros setting it in a wrong way.
So, it will be interesting to see any data you have with and without
this change.
Alternatives to explore would be:
- Can we identify some characteristics of this system and turn this on
automatically instead of user tunable.
- Long standing goal of combining conservative and ondemand with a
mode_switch at the driver load, instead of run time tunables.
Thanks,
Venki
next prev parent reply other threads:[~2009-07-08 16:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-08 13:56 Corrado Zoccolo
2009-07-08 14:18 ` Michael S. Zick
2009-07-08 17:45 ` Corrado Zoccolo
2009-07-08 16:10 ` Matthew Garrett
2009-07-08 16:33 ` Pallipadi, Venkatesh [this message]
2009-07-08 18:05 ` Corrado Zoccolo
2009-07-08 17:41 ` Corrado Zoccolo
2009-07-08 17:47 ` Matthew Garrett
2009-07-14 14:37 ` Corrado Zoccolo
2009-07-09 23:34 ` Pavel Machek
2009-07-14 14:44 ` Corrado Zoccolo
2009-07-14 14:59 ` Matthew Garrett
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=1247070794.11545.123.camel@localhost.localdomain \
--to=venkatesh.pallipadi@intel.com \
--cc=cpufreq@vger.kernel.org \
--cc=czoccolo@gmail.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.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
Powered by JetHome