lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100423153503.GA14832@1wt.eu>
Date:	Fri, 23 Apr 2010 17:35:03 +0200
From:	Willy Tarreau <w@....eu>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Pavel Machek <pavel@....cz>, 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:10:50AM -0700, Arjan van de Ven wrote:
> On Fri, 23 Apr 2010 07:38:58 +0200
> Willy Tarreau <w@....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

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ