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

[Mark Lord <lkml@rtr.ca>]

Pallipadi, Venkatesh wrote:
>  
> 
>> -----Original Message-----
>> From: Andrew Morton [mailto:akpm@linux-foundation.org] 
>> Sent: Wednesday, January 02, 2008 4:52 PM
>> To: Pallipadi, Venkatesh
>> Cc: Mark Lord; Arjan van de Ven; abelay@novell.com; 
>> lenb@kernel.org; Ingo Molnar; linux-kernel@vger.kernel.org; 
>> linux-acpi@vger.kernel.org
>> Subject: Re: + restore-missing-sysfs-max_cstate-attr.patch 
>> added to -mm tree
>>
>> On Wed, 2 Jan 2008 16:06:20 -0800 "Pallipadi, Venkatesh" 
>> <venkatesh.pallipadi@intel.com> wrote:
>>
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Mark Lord [mailto:lkml@rtr.ca] 
>>>> Sent: Wednesday, January 02, 2008 3:42 PM
>>>> To: Arjan van de Ven
>>>> Cc: Pallipadi, Venkatesh; Andrew Morton; abelay@novell.com; 
>>>> lenb@kernel.org; Ingo Molnar; linux-kernel@vger.kernel.org; 
>>>> linux-acpi@vger.kernel.org
>>>> Subject: Re: + restore-missing-sysfs-max_cstate-attr.patch 
>>>> added to -mm tree
>>>>
>>>> Arjan van de Ven wrote:
>>>>> On Fri, 30 Nov 2007 22:31:17 -0500
>>>>> Mark Lord <lkml@rtr.ca> wrote:
>>>>>
>>>>>> Arjan van de Ven wrote:
>>>>>>> On Fri, 30 Nov 2007 22:14:08 -0500
>>>>>>> Mark Lord <lkml@rtr.ca> 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 ?
>>>>
>>> Easiest and clean way to do it is to have a driver with
>>> set_acceptable_latency() for 1uS or so in init and
>>> remove_acceptable_latency() at exit.
>> err, you appear to be suggesting that Mark patch his kernel to 
>> make it work
>> as well as 2.6.23?  That would be a wrong answer.
>>
>> This regression was known six weeks ago.  What do we need to 
>> do (or revert)
>> to fix it in 2.6.24?
>>
> 
> As I responded earlier here
> http://www.ussg.iu.edu/hypermail/linux/kernel/0711.3/2348.html
> 
> This interface cannot be supported cleanly with cpuidle. The cleanest
> way to do this is to go through latency interfaces. We have changed all
> in kernel drivers to use this new interface. The issue here is, I
> removed this sysfs interface without depracting it. We can call it a
> regression and we can add it back for the moment. But, this will go from
> sysfs sooner or later and latency interface has to be used in future.
> And Mark earlier responded in this thread saying he is OK with adding
> something in the kernel to get this working, That is the reason I
> suggested the above option.
..

I'm fine with switching to a new interface, and even supplying my own
kernel module to do so.  But it doesn't produce the required effect
on the single-core machine we just switched over to 2.6.24
(and then promptly switched back again!).

There should be some way to get it to work with similar minimal latency
to the old "echo 1 > max_cstate" logic, but I've yet to discover it.

I wonder if the "new" latency interfaces actually work ?

> As I saw it 6 weeks back, max_cstate option works as a boot parameter.
..

That's no good.  It has to be changeable on the fly, rather than requiring
the machine be rebooted each time.

Cheers