Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

From: Mark Lord
Date: Wed Jan 02 2008 - 18:42:26 EST


Arjan van de Ven wrote:
On Fri, 30 Nov 2007 22:31:17 -0500
Mark Lord <lkml@xxxxxx> wrote:

Arjan van de Ven wrote:
On Fri, 30 Nov 2007 22:14:08 -0500
Mark Lord <lkml@xxxxxx> wrote:

in -mm there is.. the QoS stuff allows you to set maximum
tolerable
..

That's encouraging, I think, but not for 2.6.24.

latency. If your app cant take any latency, you should set
those... and the side effect is that the kernel will not do
long-latency C-states or P-state transitions..
..

I don't mind the cpufreq changing (actually, I want it to drop in
cpugfreq to save power and keep the fan off), but the C-states just
kill this app.

The app is VMware. I force the max_state=1 when launching,
ah but then its' even easier... and can be done in 2.6.24 already.
VMWare after all has a kernel module, and the latency stuff is in
2.6.23 and 2.6.24 available inside the kernel already.
..

Oh, I'm perfectly happy to write my own kernel module if that's what

all you need to do in your kernel module is call

add_latency_constraint("mark_wants_his_mouse", 5);

or so
..

Dredging up an old regression again now:

The "make my own module to replace /sys/.../max_cstate" doesn't work
for the single-core machine we use a lot around here.

VMware is totally sluggish unless I go to another text window and do this:

while ( true ); do echo -n ; done

At which point VMware performs well again,
the same as with "echo 1 > max_cstate" in 2.6.23.

Anyone got any suggestions on how to fix this regression
or work around it for 2.6.24 ?

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/