From: Willy Tarreau <w@1wt.eu>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
mingo@elte.hu, peterz@infradead.org, tglx@linutronix.de,
davej@redhat.com, cpufreq@vger.kernel.org
Subject: Re: [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO
Date: Fri, 23 Apr 2010 17:35:03 +0200 [thread overview]
Message-ID: <20100423153503.GA14832@1wt.eu> (raw)
In-Reply-To: <20100423071050.715b3b33@infradead.org>
On Fri, Apr 23, 2010 at 07:10:50AM -0700, Arjan van de Ven wrote:
> On Fri, 23 Apr 2010 07:38:58 +0200
> Willy Tarreau <w@1wt.eu> wrote:
>
> > On Fri, Apr 23, 2010 at 07:24:39AM +0200, Pavel Machek wrote:
> > > Hi!
> > >
> > > > The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
> > > > time) as a measure for scaling the CPU frequency up or down.
> > > > If the CPU is busy, the CPU frequency scales up, if it's idle,
> > > > the CPU frequency scales down. Effectively, it uses the CPU busy
> > > > time as proxy variable for the more nebulous "how critical is
> > > > performance right now" question.
> > > >
> > > > This algorithm falls flat on its face in the light of workloads
> > > > where you're alternatingly disk and CPU bound, such as the ever
> > > > popular "git grep", but also things like startup of programs and
> > > > maildir using email clients... much to the chagarin of Andrew
> > > > Morton.
> > > >
> > > > This patch changes the ondemand algorithm to count iowait time as
> > > > busy, not idle, time. As shown in the breakdown cases above,
> > > > iowait is performance critical often, and by counting iowait, the
> > > > proxy variable becomes a more accurate representation of the "how
> > > > critical is performance" question.
> > >
> > > Well, and now, if you do something like cat /dev/<your usb1.1 hdd> >
> > > /dev/null, you'll keep cpu on max frequency. Not a problem for new
> > > core i7, but probably big deal for athlon 64.
> >
> > So that also means that my notebook's CPU fan will spin like mad as
> > soon as I access a USB key ?
>
> unlikely. your notebook CPU will stop its clocks, if not drop its
> voltage, during idle. So during that time the frequency is 0; the only
> difference is in how much leakage you get from a higher voltage
> for those CPUs that do not powergate or drop their cpu in idle.
> Most CPUs that I know of do either or both of that.
OK, I will have to give that a run on my Atom and Pentium-M, both of
which provide me with a very long run on battery precisely because
they almost always run at the lowest possible frequency and voltage.
On the pentium-M, I already know there is a difference between full
voltage and low voltage even when idle. Its lowest frequency is 600
MHz, and my kernel still has the old phc patch to lower clock and
voltage. When idle on this kernel, the fan is completely stopped
and never wakes up. When idle on a 2.6.32 (which does not have the
patch), its voltage doesn't drop though the frequency does, and the
fan runs at 1/4. It also lasts shorter (about 30 min less). So that
means that even when idle there's a noticeable difference.
As was suggested, if the difference appears to be significant, maybe
a /sys tunable would allow all users to select their preferred mode.
Alternatively, we could have two distinct ondemand settings, one for
pure CPU and another one for CPU+I/O.
Regards,
Willy
next prev parent reply other threads:[~2010-04-23 15:36 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-18 18:59 [PATCH 0/7] Fix performance issue with ondemand governor Arjan van de Ven
2010-04-18 19:00 ` [PATCH 1/7] sched: add a comment to get_cpu_idle_time_us() Arjan van de Ven
2010-04-26 19:25 ` Rik van Riel
2010-04-18 19:01 ` [PATCH 2/7] sched: introduce a function to update the idle statistics Arjan van de Ven
2010-04-26 20:11 ` Rik van Riel
2010-04-18 19:01 ` [PATCH 3/7] sched: update the idle statistics in get_cpu_idle_time_us() Arjan van de Ven
2010-04-26 20:36 ` Rik van Riel
2010-04-18 19:02 ` [PATCH 4/7] sched: fold updating of the last update time into update_ts_time_stats() Arjan van de Ven
2010-04-26 20:58 ` Rik van Riel
2010-04-18 19:02 ` [PATCH 5/7] sched: eliminate the ts->idle_lastupdate field Arjan van de Ven
2010-04-26 21:00 ` Rik van Riel
2010-04-18 19:03 ` [PATCH 6/7] sched: introduce get_cpu_iowait_time_us() Arjan van de Ven
2010-04-26 21:05 ` Rik van Riel
2010-04-18 19:03 ` [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO Arjan van de Ven
2010-04-19 8:29 ` Éric Piel
2010-04-19 13:43 ` Arjan van de Ven
2010-04-19 14:30 ` Éric Piel
2010-04-19 14:47 ` Arjan van de Ven
2010-04-20 9:24 ` Thomas Renninger
2010-04-27 0:29 ` Mike Chan
2010-04-27 13:01 ` Pavel Machek
2010-04-27 18:10 ` Mike Chan
2010-04-19 9:09 ` Tvrtko Ursulin
2010-04-19 13:46 ` Arjan van de Ven
2010-04-19 15:29 ` Tvrtko Ursulin
2010-04-20 0:47 ` Arjan van de Ven
2010-04-20 9:10 ` Tvrtko Ursulin
2010-04-20 11:02 ` Arjan van de Ven
2010-04-28 8:57 ` Tvrtko Ursulin
2010-04-23 5:26 ` Pavel Machek
2010-04-20 9:29 ` Thomas Renninger
2010-04-20 11:07 ` Arjan van de Ven
2010-04-23 5:24 ` Pavel Machek
2010-04-23 5:38 ` Willy Tarreau
2010-04-23 8:50 ` Thomas Renninger
2010-04-23 16:08 ` Arjan van de Ven
2010-04-27 11:39 ` Thomas Renninger
2010-05-04 3:48 ` [PATCH 8/7] cpufreq: make the iowait-is-busy-time a sysfs tunable Arjan van de Ven
2010-05-04 4:16 ` Willy Tarreau
2010-05-04 5:43 ` Pavel Machek
2010-05-04 13:51 ` Rik van Riel
2010-04-23 14:10 ` [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO Arjan van de Ven
2010-04-23 15:35 ` Willy Tarreau [this message]
2010-04-23 13:52 ` Arjan van de Ven
2010-04-23 8:38 ` Pavel Machek
2010-04-23 16:06 ` Arjan van de Ven
2010-04-24 4:56 ` Pavel Machek
2010-05-01 23:29 ` Arjan van de Ven
2010-04-26 21:30 ` Rik van Riel
2010-04-26 21:41 ` [PATCH 0/7] Fix performance issue with ondemand governor Dave Jones
2010-04-26 21:45 ` Dominik Brodowski
2010-04-26 21:59 ` Rik van Riel
2010-04-26 22:05 ` Dominik Brodowski
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=20100423153503.GA14832@1wt.eu \
--to=w@1wt.eu \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=cpufreq@vger.kernel.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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