All of lore.kernel.org
 help / color / mirror / Atom feed
From: David C Niemi <dniemi@verisign.com>
To: Vishwanath Sripathy <vishwanath.sripathy@linaro.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>,
	linaro-dev@lists.linaro.org, cpufreq@vger.kernel.org
Subject: Re: Issues with ondemand governor
Date: Wed, 24 Nov 2010 09:12:19 -0500	[thread overview]
Message-ID: <4CED1D43.6080900@verisign.com> (raw)
In-Reply-To: <AANLkTik3qRgq8EpffsusVk1puAgRdFQ7vKrf6FL=SULs@mail.gmail.com>


Thanks for running the tests, Vishwa.  Your results are what I'd expect
but it's good to see independent confirmation.  In my benchmarks I saw
95-100% of the performance governor's performance, but the conditions
were more favorable and the original ondemand governor was "only"
degrading performance 20-30% to begin with.

There should be absolutely no changes in power consumption at all for
the patch itself, as behavior does not change until you raise
sampling_down_factor above 1 (the default).  If you set it high, I would
expect higher power consumption (but also higher performance) under load
and no change in power consumption when idle or close to idle.  Setting
a high sampling_down_factor causes the governor to reevaluate load less
often when at max cpu speed, both to reduce overhead and to let it
remain at maximum performance more consistently.  Without this change,
the ondemand governor jitters a lot in and out of max clock speed when
under high loads, which is why its performance can be much worse than
the performance governor.  Reducing the number of transitions and load
evaluations should also improve performance per watt, though the details
of that depend on the relative efficiency of the CPU's respective clock
speeds.

If you want to balance power consumption and performance, a middle
setting of sampling_down_factor like "10" should make a noticeable
improvement in performance while not having as much impact on power. 
But if you want to match the performance governor's performance and are
less concerned about transient power consumption, you will want to set
it higher.

Another note: I recommend setting io_is_busy to 1 when using
sampling_down_factor above 1, as it improves responsiveness to quick
load transients involving some I/O.  It's also worth considering
lowering up_threshold to 50 or even down to 15-20.

David C Niemi

Vishwanath Sripathy wrote:
> Amit,
>
> On Tue, Nov 23, 2010 at 8:22 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>   
>> Vishwa,
>>
>> Have you had a chance to do some usetime tests with these changes?
>>     
> I did test USB performance with this and I see ondmeand is 90% close
> to performance.
>   
>> It would be interesting to measure the power consumption with and
>> without these changes.
>>     
> Power consumption impact can vary from usecase to usecase and extra
> performance will have some power impact.
> However in idle scenario, I feel this should not have much impact
> since ondemand timer is a deferrable timer which means that it does
> not prevent cpuidle. I will try to measure it for some usecase and
> compare the power impact.
>
> Vishwa
>   

  reply	other threads:[~2010-11-24 14:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 13:18 Issues with ondemand governor Vishwanath Sripathy
2010-11-22 16:09 ` David C Niemi
2010-11-23 12:29   ` Vishwanath Sripathy
2010-11-23 14:52     ` Amit Kucheria
2010-11-24 11:57       ` Vishwanath Sripathy
2010-11-24 14:12         ` David C Niemi [this message]
2010-11-25 12:05           ` Vishwanath Sripathy
2010-11-25 14:31             ` Thomas Renninger
     [not found]   ` <4CEA959F.9000505-0nFLJxsdniVWk0Htik3J/w@public.gmane.org>
2010-11-26 22:38     ` Christian Robottom Reis
     [not found]       ` <20101126223815.GU30563-J1k5CargkBPB0jqWMgOSsQh0onu2mTI+@public.gmane.org>
2010-11-29  9:05         ` Vishwanath Sripathy
2010-11-29 15:16       ` David C Niemi
     [not found]         ` <4CF3C3B4.3000209-0nFLJxsdniVWk0Htik3J/w@public.gmane.org>
2010-11-29 15:38           ` Nicolas Pitre
2010-11-29 18:00             ` Dave Jones
2010-11-29 20:03               ` David C Niemi

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=4CED1D43.6080900@verisign.com \
    --to=dniemi@verisign.com \
    --cc=amit.kucheria@linaro.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=linaro-dev@lists.linaro.org \
    --cc=vishwanath.sripathy@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.