Arjan van de Ven wrote:
quoted text
> On Fri, 30 Nov 2007 21:52:40 -0500
> Mark Lord <lkml@rtr.ca> wrote:
> 
>> Pallipadi, Venkatesh wrote:
> 
>>> Exporting it as read only should be OK. We also need to know if
>>> there are hard user space dependency on writing to this from
>>> userspace.
>> ..
>>
>> Well, actually..  my scripts have a firm need to write "1" to it,
>> and then later restore the original value.
>>
>> This is needed to *greatly* speed up an otherwise sluggish binary I
>> use, 
> 
> just curious, but this does sound like the c-state code has a bug...
> independent of the sysfs thing, I think that really needs solving
> 
> Can you describe the behavior a little? Or provide information to the
> degree that some of us can figure out how to tweak the algorithm..,.
> 
> 
>> as well as whenever I want to semi-accurately benchmark I/O.
>>
>> Is there another way to achieve exactly the same behaviour?
> 
> in -mm there is.. the QoS stuff allows you to set maximum tolerable
..

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

quoted text
> 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,
and restore it to (prior value) 8 when it exits.
Makes a *huge* difference for text input and the like.
Yes, there's something there that could get fixed in the app,
and maybe one day will get fixed.  But I'm not holding my breath.

I think it manages to resonate at exactly the harmonic required that
the chip transitions to C?? just prior to the app wanting to wake up 
and do another poll.  Just kills it.

I'm not sure about C?? -- it could be C8 or even be C2 or whatever.
I suppose I should find out, but that really takes a lot of fuss (hours)
to measure, and isn't strictly repeatable.



 

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