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
next prev parent reply other threads:[~2010-09-13 22:02 UTC|newest]
Thread overview: 15+ 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-18 10:13 ` Sripathy, Vishwanath
2010-09-17 13:45 ` David C Niemi
2010-09-17 13:46 ` Arjan van de Ven
2010-09-17 13:46 ` Arjan van de Ven
2010-09-17 9:25 ` Thomas Renninger
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 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.