From: Andi Kleen <andi@firstfloor.org>
To: David C Niemi <dniemi@verisign.com>
Cc: cpufreq@vger.kernel.org, lenb@kernel.org
Subject: Re: Improving High-Load Performance with the Ondemand Governor
Date: Mon, 13 Sep 2010 22:54:56 +0200 [thread overview]
Message-ID: <20100913225456.13cbbaef@basil.nowhere.org> (raw)
In-Reply-To: <4C8E872B.2020503@verisign.com>
On Mon, 13 Sep 2010 16:18:51 -0400
David C Niemi <dniemi@verisign.com> wrote:
> > > I have tested patches for both 2.6.18 and 2.6.32, but before
> > > sharing them I'd like to first describe the problem I'm trying to
> > > solve and the strategy I've been trying and get some feedback on
> > > it.
> >
> > These are all ancient in terms of mainline kernel. The latest
> > kernel should have some improvements, perhaps try them first.
> >
> 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)
> > 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.
> 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.
> > ondemand and p-states mainly help you on moderate load.
> >
> > Just going to highest state unconditionally would be somewhat
> > contraproductive to that goal.
> >
> 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
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-09-13 20:54 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 [this message]
2010-09-13 22:02 ` David C Niemi
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-17 13:45 ` David C Niemi
2010-09-18 10:13 ` Sripathy, Vishwanath
2010-09-18 10:13 ` [linux-pm] " Sripathy, Vishwanath
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=20100913225456.13cbbaef@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=cpufreq@vger.kernel.org \
--cc=dniemi@verisign.com \
--cc=lenb@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.