[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100423053858.GE7798@1wt.eu>
Date: Fri, 23 Apr 2010 07:38:58 +0200
From: Willy Tarreau <w@....eu>
To: Pavel Machek <pavel@....cz>
Cc: Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
mingo@...e.hu, peterz@...radead.org, tglx@...utronix.de,
davej@...hat.com, cpufreq@...r.kernel.org
Subject: Re: [PATCH 7/7] ondemand: Solve the big performance issue with ondemand during disk IO
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 ? It will not help the key go faster...
Probably that iowait should only change the time required to go back to
low frequency. That way, if there is no CPU nor I/O activity, we can
switch back to a low frequency quickly, but if we see I/O activity, we
could decide to wait for 1 second (for instance) for CPU idle before
switching back to low frequency.
> Maybe modern cpus can and should simply react faster?
It's above all that we should not try to switch too fast if we know the
CPU can't follow.
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists