linux-kernel - RE: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

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: <924EFEDD5F540B4284297C4DC59F3DEE4FC4E4@orsmsx423.amr.corp.intel.com>
Date:	Wed, 2 Jan 2008 17:12:43 -0800
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Mark Lord" <lkml@....ca>,
	"Arjan van de Ven" <arjan@...radead.org>, <abelay@...ell.com>,
	<lenb@...nel.org>, "Ingo Molnar" <mingo@...e.hu>,
	<linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>
Subject: RE: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

 

>-----Original Message-----
>From: Andrew Morton [mailto:akpm@...ux-foundation.org] 
>Sent: Wednesday, January 02, 2008 4:52 PM
>To: Pallipadi, Venkatesh
>Cc: Mark Lord; Arjan van de Ven; abelay@...ell.com; 
>lenb@...nel.org; Ingo Molnar; linux-kernel@...r.kernel.org; 
>linux-acpi@...r.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@...el.com> wrote:
>
>>  
>> 
>> >-----Original Message-----
>> >From: Mark Lord [mailto:lkml@....ca] 
>> >Sent: Wednesday, January 02, 2008 3:42 PM
>> >To: Arjan van de Ven
>> >Cc: Pallipadi, Venkatesh; Andrew Morton; abelay@...ell.com; 
>> >lenb@...nel.org; Ingo Molnar; linux-kernel@...r.kernel.org; 
>> >linux-acpi@...r.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@....ca> wrote:
>> >> 
>> >>> Arjan van de Ven wrote:
>> >>>> On Fri, 30 Nov 2007 22:14:08 -0500
>> >>>> Mark Lord <lkml@....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.

As I saw it 6 weeks back, max_cstate option works as a boot parameter. I
did not see anyone else (apart from Mark) saying they are depending on
this sysfs interface to change max_cstate at run time and Mark said he
can do with the kernel change if possible. Please let me know if you
think this interface is a must fix for .24. I will send a minimal patch
to add it back for .24 for !CPU_IDLE case.

Thanks,
Venki 
--
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/