cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David C Niemi <dniemi@verisign.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: cpufreq@vger.kernel.org
Subject: Re: Improving High-Load Performance with the Ondemand Governor
Date: Mon, 13 Sep 2010 18:02:17 -0400	[thread overview]
Message-ID: <4C8E9F69.3020502@verisign.com> (raw)
In-Reply-To: <20100913225456.13cbbaef@basil.nowhere.org>

Andi Kleen wrote:
> On Mon, 13 Sep 2010 16:18:51 -0400
> David C Niemi <dniemi@verisign.com> wrote:
>
>   
>> I have looked at the latest kernels too, and the changes in the
>> ondemand governor between that and RHEL 6's 2.6.32 kernel are quite
>> modest.  I mention 2.6.18 just because it's what's been out in the
>> field a while.
>>     
>
> Most of the interesting changes were post 2.6.32 (2.6.32 is ancient
> too for mainline)  
>   
I did see a few changes in cpufreq_ondemand.c between 2.6.32 and the git 
version I grabbed last week, but not really relevant to what I was 
trying to do.

>>> FWIW when you're truly idle you typically don't need ondemand,
>>> the idle states on modern CPUs go to the lowest frequency by
>>> themselves or simply turn off the frequency completely.
>>>
>>>       
>> I do see c-states getting used on Intel hardware to save power, and
>>     
>
> ondemand has nothing to do with c-states, c-states are handled
> by the menu governor.
>   
We're using the standard cpuidle on the newer (RHEL 6 beta-based) 
kernels.  If you think there are compelling improvements in it after 
2.6.32 I'll certainly take a look.
 
>> in some cases these are quite effective.  On AMD hardware lowering 
>> frequency tends to be very important to saving power.
>>     
>
> AFAIK modern AMD doesn't need this either in c-states.
>   
It makes a dramatic difference in power consumption whether you use a 
p-state governor on the 2-year-old AMD hardware that matters to me.  On 
both old (Woodcrest) and new (Nehalem) Intel hardware the difference is 
much smaller, as c-states are the dominant form of power saving, but 
using a p-state governor still makes a measurable difference.  On the 
plus side the power-saving c-states we are using don't measurably hurt 
performance on our workloads, so cpuidle is doing a pretty good job; 
whereas the stock ondemand p-state governor does in a big way.

>> On moderate load I might agree, but on the servers I care about it is
>> a workload that's a bit like war -- long periods of boredom
>> punctuated by sudden bursts of sheer terror. 
>>     
>
> In this case on modern hardware you don't need a p-state
> governor at all except for "performance"
>
> -Andi
>   
No doubt true in the long run, but see above.

DCN

  reply	other threads:[~2010-09-13 22:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09 14:28 Improving High-Load Performance with the Ondemand Governor David C Niemi
2010-09-10  7:40 ` Andi Kleen
2010-09-13 20:18   ` David C Niemi
2010-09-13 20:54     ` Andi Kleen
2010-09-13 22:02       ` David C Niemi [this message]
2010-09-16 20:39 ` Improving High-Load Performance with the Ondemand Governor [PATCH ATTACHED] David C Niemi
2010-09-17  9:25   ` Thomas Renninger
2010-09-17 13:45     ` David C Niemi
2010-09-18 10:13       ` [linux-pm] " Sripathy, Vishwanath
2010-09-17 13:46     ` Arjan van de Ven
2010-09-29 18:18   ` Venkatesh Pallipadi

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=4C8E9F69.3020502@verisign.com \
    --to=dniemi@verisign.com \
    --cc=andi@firstfloor.org \
    --cc=cpufreq@vger.kernel.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