[PATCHES] add _CST support

[PATCHES] add _CST support

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

On top of the processor.c splitup patchset announced earlier today I've
rediffed, modified and split up the _CST patches originally developed by Bruno Ducrot 
(i.e. the static approach, not my broken dynamic patch) and tracked at 
http://bugme.osdl.org/show_bug.cgi?id=1958 .

A "bigdiff" which should apply cleanly on top of 2.6.10-rc2-mm3 is available at
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~176KB)
and zipped
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~36KB)

To apply the following individual patches, you first need the processor.c splitup patches:
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-processor-splitup-perflib
http://www.brodo.de/patches/2004-11-27/02-acpi-20041127-processor-splitup-throttling
http://www.brodo.de/patches/2004-11-27/03-acpi-20041127-processor-splitup-idle
http://www.brodo.de/patches/2004-11-27/04-acpi-20041127-processor-splitup-thermal
http://www.brodo.de/patches/2004-11-27/05-acpi-20041127-processor-splitup-core
http://www.brodo.de/patches/2004-11-27/06-acpi-20041127-throttling-disableirqsforshorterperiods

Please test + apply,
	Dominik



http://www.brodo.de/patches/2004-11-27/07-acpi-20041127-cst-type

It's important to make a difference between the actual C-States and the
_type_ of the C-State. While they're always equal for ACPI 1.0 systems,
they can differ for ACPI 2.0 or later systems. Therefore, use _type_
wherever appropriate.


http://www.brodo.de/patches/2004-11-27/08-acpi-20041127-fadtpblk

Split up the extraction of information from the FADT and the pblk_address
(acpi_processor_get_power_info_fadt()) and the validation whether the state
is indeed available (acpi_processor_power_verify()).


http://www.brodo.de/patches/2004-11-27/09-acpi-20041127-power-remove-default-state

"default_state" is unused, so remove it.


http://www.brodo.de/patches/2004-11-27/10-acpi-20041127-make-power-state-a-pointer

Make the current "state" in struct acpi_processor_power a pointer. If it
doesn't exist, simply use C1 type sleep...


http://www.brodo.de/patches/2004-11-27/11-acpi-20041127-power-policy-independent-of-states

- make the state a pointer inside struct acpi_processor_cx_policy,
- make acpi_cstate_limit aware of c-state types instead of numbers, as the
	latter mean (almost) nothing
- make the policy decisions of demotion and promotion independent of
	the assumption "one state per type"


http://www.brodo.de/patches/2004-11-27/12-acpi-20041127-cst-parsing

Add parsing for _CST


http://www.brodo.de/patches/2004-11-27/13-acpi-20041127-cst-change

Add a notifier for _CST changing events. It is necessary to unload
the processor idle handle for a short period of time to avoid for nasty
races -- and we don't want to grab too many locks so that the idle handler
continues to be speedy.


http://www.brodo.de/patches/2004-11-27/14-acpi-20041127-cst-notify_smm

Notify the BIOS that we can handle _CST.


http://www.brodo.de/patches/2004-11-27/15-acpi-20041127-power-only-init-modify-exit

Consolidate code in processor_idle(). Only symbols "exported" are
_init(), _exit() and _cst_has_changed().


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCHES] add _CST support

[Dominik Brodowski]

> and zipped
> http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~36KB)
http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete.gz

Sorry,
	Dominik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [PATCHES] add _CST support

[Len Brown]

On Sat, 2004-11-27 at 16:51, Dominik Brodowski wrote:

> - make acpi_cstate_limit aware of c-state types instead of numbers, as the
> 	latter mean (almost) nothing

While both C3 and C4 will be of type-C3, I'd like to still be able to
disable C4 without disabling C3.

-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Dominik Brodowski]

On Wed, Dec 22, 2004 at 12:44:05AM -0500, Len Brown wrote:
> On Sat, 2004-11-27 at 16:51, Dominik Brodowski wrote:
> 
> > - make acpi_cstate_limit aware of c-state types instead of numbers, as the
> > 	latter mean (almost) nothing
> 
> While both C3 and C4 will be of type-C3, I'd like to still be able to
> disable C4 without disabling C3.

If we can agree not to call it "C3" and "C4", yes... The problem is the 
C-nomination is sort of a _type_ which is overloaded with the actual states.
I.e. you could have C0 state, C1 state, 2 different C2 states, and 2
different C3 states. Then you'd have

number	type	overloaded C-notation

0	C0	C0
1	C1	C1
2	C2	C2
3	C2	C3	<--- confusion/breakage
4	C3	C4
5	C3	C5

Also, drivers like the ipw driver will want to disable all of _type_ C3
sleep, AFAICS. Therefore, if you want to limit it by number instead of type
as well, I'd suggest to add another differently named parameter.

	Dominik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Len Brown]

On Wed, 2004-12-22 at 19:08, Dominik Brodowski wrote:
> On Wed, Dec 22, 2004 at 12:44:05AM -0500, Len Brown wrote:
> > On Sat, 2004-11-27 at 16:51, Dominik Brodowski wrote:
> >
> > > - make acpi_cstate_limit aware of c-state types instead of
> numbers, as the latter mean (almost) nothing
> >
> > While both C3 and C4 will be of type-C3, I'd like to still be able
> to disable C4 without disabling C3.
> 
> If we can agree not to call it "C3" and "C4", yes... The problem is
> the C-nomination is sort of a _type_ which is overloaded with the
> actual states.

C-states are enumerated C0...Cn
C-state types are enumerated C1, C2, C3.
I don't see any confusion in the name-space duplicates
as long as you know you're talking about C-states or C-state-types.

> I.e. you could have C0 state, C1 state, 2 different C2 states, and 2
> different C3 states. Then you'd have
> 
> number  type    overloaded C-notation
> 
> 0       C0      C0
> 1       C1      C1
> 2       C2      C2
> 3       C2      C3      <--- confusion/breakage
> 4       C3      C4
> 5       C3      C5

while it is probably unlikely for a system to supply
multiple C2-type states, it would be perfectly legal
and should not cause either confusion or breakage.

> Also, drivers like the ipw driver will want to disable all of _type_
> C3 sleep, AFAICS. Therefore, if you want to limit it by number instead
> of type as well, I'd suggest to add another differently named
> parameter.

I'd rather delete the workaround than further complicate it.

The workaround specifies the maximum C-state allowed (max_cstate) -- it
doesn't specify the minimum C-state type dis-allowed.
So when ipw2100 says acpi_set_cstate_limit(2), this will always work.
Yes, you could invent a system like this

type c-state
C1	C1
C3	C2
C3	C3

and that would break.  But by the time somebody invents that
system, the ipw2100 which needs this workaround will not be present.  It
has been replaced by the 2200BG, which has been replaced by the 2915ABG.

-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Pavel Machek]

Hi!

> > > > - make acpi_cstate_limit aware of c-state types instead of
> > numbers, as the latter mean (almost) nothing
> > >
> > > While both C3 and C4 will be of type-C3, I'd like to still be able
> > to disable C4 without disabling C3.
> > 
> > If we can agree not to call it "C3" and "C4", yes... The problem is
> > the C-nomination is sort of a _type_ which is overloaded with the
> > actual states.
> 
> C-states are enumerated C0...Cn
> C-state types are enumerated C1, C2, C3.
> I don't see any confusion in the name-space duplicates
> as long as you know you're talking about C-states or C-state-types.
> 

Unfortunately, people often don't know what they are talking about.
Having two things called C2 is definitely going to confuse just
about everyone but you...

Can't you #define C2type 2 or something? There has to be better
name for all this.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Len Brown]

On Thu, 2004-12-23 at 08:07, Pavel Machek wrote:

> > C-states are enumerated C0...Cn
> > C-state types are enumerated C1, C2, C3.
> > I don't see any confusion in the name-space duplicates
> > as long as you know you're talking about C-states or C-state-types.
> >
> 
> Unfortunately, people often don't know what they are talking about.
> Having two things called C2 is definitely going to confuse just
> about everyone but you...

Probably we should not mess with the "well known" (hah;-) name space for
C-states themselves (C0...Cn).

Types, on the other hand, would probably be well addressed with a enum
whose vales are 1,2,3 so if we chose to print them out they'd simply be
a %d -- using C%d only for actual C-states themselves.

would that be better?





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Dominik Brodowski]

On Mon, Dec 27, 2004 at 10:27:15PM -0500, Len Brown wrote:
> On Thu, 2004-12-23 at 08:07, Pavel Machek wrote:
> 
> > > C-states are enumerated C0...Cn
> > > C-state types are enumerated C1, C2, C3.
> > > I don't see any confusion in the name-space duplicates
> > > as long as you know you're talking about C-states or C-state-types.
> > >
> > 
> > Unfortunately, people often don't know what they are talking about.
> > Having two things called C2 is definitely going to confuse just
> > about everyone but you...
> 
> Probably we should not mess with the "well known" (hah;-) name space for
> C-states themselves (C0...Cn).
> 
> Types, on the other hand, would probably be well addressed with a enum
> whose vales are 1,2,3 so if we chose to print them out they'd simply be
> a %d -- using C%d only for actual C-states themselves.
> 
> would that be better?

I _still_ favour using C0 to C3 for the types, as the meaning of this is
probably better known [e.g. the implications of C3 to bus mastering], and
invent something new (like I0 to In for idle states?) and hope the ACPI
specification group will like this naming and "clarify" it in ACPI 2./3.x

However, I guess we do have to live with a broken ACPI specification in this
regard... But it is an imperfect world, after all :-)

	Dominik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Pavel Machek]

Hi!

> > > C-states are enumerated C0...Cn
> > > C-state types are enumerated C1, C2, C3.
> > > I don't see any confusion in the name-space duplicates
> > > as long as you know you're talking about C-states or C-state-types.
> > >
> > 
> > Unfortunately, people often don't know what they are talking about.
> > Having two things called C2 is definitely going to confuse just
> > about everyone but you...
> 
> Probably we should not mess with the "well known" (hah;-) name space for
> C-states themselves (C0...Cn).
> 
> Types, on the other hand, would probably be well addressed with a enum
> whose vales are 1,2,3 so if we chose to print them out they'd simply be
> a %d -- using C%d only for actual C-states themselves.
> 
> would that be better?

Yes.... With right setup we can even do type-checking with sparse.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [PATCHES] add _CST support

[Len Brown]

On Sat, 2004-11-27 at 16:51, Dominik Brodowski wrote:
> On top of the processor.c splitup patchset announced earlier today I've
> rediffed, modified and split up the _CST patches originally developed by Bruno Ducrot 
> (i.e. the static approach, not my broken dynamic patch) and tracked at 
> http://bugme.osdl.org/show_bug.cgi?id=1958 .
> 
> A "bigdiff" which should apply cleanly on top of 2.6.10-rc2-mm3 is available at
> http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~176KB)
> and zipped
> http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-complete (~36KB)
> 
> To apply the following individual patches, you first need the processor.c splitup patches:
> http://www.brodo.de/patches/2004-11-27/01-acpi-20041127-processor-splitup-perflib
> http://www.brodo.de/patches/2004-11-27/02-acpi-20041127-processor-splitup-throttling
> http://www.brodo.de/patches/2004-11-27/03-acpi-20041127-processor-splitup-idle
> http://www.brodo.de/patches/2004-11-27/04-acpi-20041127-processor-splitup-thermal
> http://www.brodo.de/patches/2004-11-27/05-acpi-20041127-processor-splitup-core
> http://www.brodo.de/patches/2004-11-27/06-acpi-20041127-throttling-disableirqsforshorterperiods
> 
> Please test + apply,
> 	Dominik

Applied to 26-latest-test tree.
(did not back-port to the 2.6.9-based 26-stable-test tree)

I found I had to disable the bm_check to get out of C1
on my D600.  This doesn't sound right, as bm_check
should only have an effect on entering C3.

I used options processor max_cstate=42
in /etc/modprobe.conf to make sure this
value defaulting to 3 isn't an issue,
but still unable to get into C4:

 cat /proc/acpi/processor/CPU0/power
active state:            3
max_cstate:              C42
bus master activity:     00000000
states:
    1:                  type[C1] promotion[2] demotion[-] latency[001]
usage[00000010]
    2:                  type[C2] promotion[3] demotion[1] latency[001]
usage[00003280]
   *3:                  type[C3] promotion[4] demotion[2] latency[085]
usage[00000819]
    4:                  type[C3] promotion[-] demotion[2] latency[185]
usage[00000000]

It appears the demotion from C4 is to C2, when one would expect C3.

thanks,
-Len

ps. I've seen an issue with the refernece count on processor
module reaching 2 and prevening unloading, but haven't isolated it yet.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [PATCHES] add _CST support

[Len Brown]

I removed the D600 from the port replicator, and now
it is able to run in C4 w/o any hacks:

# cat /proc/acpi/processor/CPU0/power
active state:            2
max_cstate:              C3
bus master activity:     02000001
states:
    1:                  type[C1] promotion[2] demotion[-] latency[001]
usage[00111360]
   *2:                  type[C2] promotion[3] demotion[1] latency[001]
usage[00085464]
    3:                  type[C3] promotion[4] demotion[2] latency[085]
usage[00039905]
    4:                  type[C3] promotion[-] demotion[2] latency[185]
usage[00453561]

So a list of things we need comes to mind:
Enable > C1 on SMP
max_cstate able to disable C4 w/o disabling C3
"nocst" flag to compare FADT method w/ _CST
bm_check code fix -- currently has no clue of HZ
	a 100HZ kernel gets into C4 less than
	a 1000HZ kernel, likely because of this.
tick-less idle loop

cheers,
-Len

ps.
I haven't been able to reproduce the rmmod processor failure,
though I did have a console log to show that I wasn't halucinating
at 2AM this morning:

[root@d600 root]# rmmod processor
ERROR: Module processor is in use by thermal
[root@d600 root]# rmmod thermal
[root@d600 root]# rmmod processor
ERROR: Module processor is in use
[root@d600 root]# lsmod
Module                  Size  Used by
video                  20548  0
processor              30504  2
fan                     4228  0
container               4128  0
button                  6608  0
battery                10852  0
ac                      4740  0
[root@d600 root]# rmmod container
[root@d600 root]# rmmod processor
ERROR: Module processor is in use
[root@d600 root]# lsmod
Module                  Size  Used by
video                  20548  0
processor              30504  2
fan                     4228  0
button                  6608  0
battery                10852  0
ac                      4740  0




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Dominik Brodowski]

On Wed, Dec 22, 2004 at 03:37:32PM -0500, Len Brown wrote:
> I removed the D600 from the port replicator, and now
> it is able to run in C4 w/o any hacks:
Glad to hear that. Was the port replicator causing some sort of periodic bus
master activity which keeps it out of getting to C4 sleep?

> So a list of things we need comes to mind:
- wait and see if issues appear with the split-up and _CST addition
- > Enable > C1 on SMP
... this I'd like to delay a short bit until we make the idle state
algorithm a bit smarter.
- > max_cstate able to disable C4 w/o disabling C3
... see other post, suggesting max_idle_state instead
- > "nocst" flag to compare FADT method w/ _CST
- > bm_check code fix -- currently has no clue of HZ
 > 	a 100HZ kernel gets into C4 less than
 > 	a 1000HZ kernel, likely because of this.
... Yes, this is a bug IMHO. Also, if the idle loop hasn't been entered for one
(or two? or hundred?) ticks, I think it should re-start at C1-type sleep.
- > tick-less idle loop
- _CSD support (depends on _OSC/_PDC framework)

> ps.
> I haven't been able to reproduce the rmmod processor failure,
> though I did have a console log to show that I wasn't halucinating
> at 2AM this morning:

Hm. Did you use some cpufreq module? Will stress-test the processor module
in a few hours, after I get some sleep...

Thanks,
	Dominik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Len Brown]

On Wed, 2004-12-22 at 19:18, Dominik Brodowski wrote:
> On Wed, Dec 22, 2004 at 03:37:32PM -0500, Len Brown wrote:
> > I removed the D600 from the port replicator, and now
> > it is able to run in C4 w/o any hacks:
> Glad to hear that. Was the port replicator causing some sort of
> periodic bus master activity which keeps it out of getting to C4
> sleep?

Yes, bus-master activity went from always on to sometimes on.
Maybe there is a USB hub in the port replicator...

> 
> > So a list of things we need comes to mind:
> - wait and see if issues appear with the split-up and _CST addition

I'll push this into 2.6.11 as soon as it opens up,
so it should get broad exposure quite quickly, and quite
early in the release cycle.

> - > Enable > C1 on SMP
> ... this I'd like to delay a short bit until we make the idle state
> algorithm a bit smarter.

Bob and Venki prototyped updated algorithms a while back.
I'm hopeful that they can port that work to the new code
and it can make early 2.6.11 also.

> - > max_cstate able to disable C4 w/o disabling C3
> ... see other post, suggesting max_idle_state instead
> - > "nocst" flag to compare FADT method w/ _CST
> - > bm_check code fix -- currently has no clue of HZ
>  >      a 100HZ kernel gets into C4 less than
>  >      a 1000HZ kernel, likely because of this.
> ... Yes, this is a bug IMHO.

I think the bug is that our sampling of BM activity ages
10x faster in the 1000HZ case.

>  Also, if the idle loop hasn't been entered for one
> (or two? or hundred?) ticks, I think it should re-start at C1-type
> sleep.

Agreed.  The current promote/demote code looks at idleness when it
should look at busy-ness and system load.

> - > tick-less idle loop
> - _CSD support (depends on _OSC/_PDC framework)

We need to handle SMP C-states even if the system doesn't
supply us with _CSD.

cheers,
-Len







-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Dominik Brodowski]

> I found I had to disable the bm_check to get out of C1
> on my D600.  This doesn't sound right, as bm_check
> should only have an effect on entering C3.

Huh, yes, this sounds like a bug. Can't reproduce it here, though :-(

>  cat /proc/acpi/processor/CPU0/power
> active state:            3
> max_cstate:              C42
> bus master activity:     00000000
> states:
>     1:                  type[C1] promotion[2] demotion[-] latency[001]
> usage[00000010]
>     2:                  type[C2] promotion[3] demotion[1] latency[001]
> usage[00003280]
>    *3:                  type[C3] promotion[4] demotion[2] latency[085]
> usage[00000819]
>     4:                  type[C3] promotion[-] demotion[2] latency[185]
> usage[00000000]
> 
> It appears the demotion from C4 is to C2, when one would expect C3.

Actually, this was on purpose: I think we want to leave C3-type sleep
quickly to advance bus master activity...

	Dominik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [PATCHES] add _CST support

[Len Brown]

On Wed, 2004-12-22 at 19:10, Dominik Brodowski wrote:
> > I found I had to disable the bm_check to get out of C1
> > on my D600.  This doesn't sound right, as bm_check
> > should only have an effect on entering C3.
> 
> Huh, yes, this sounds like a bug. Can't reproduce it here, though :-(

neither can I...

> >  cat /proc/acpi/processor/CPU0/power
> > active state:            3
> > max_cstate:              C42
> > bus master activity:     00000000
> > states:
> >     1:                  type[C1] promotion[2] demotion[-]
> latency[001]
> > usage[00000010]
> >     2:                  type[C2] promotion[3] demotion[1]
> latency[001]
> > usage[00003280]
> >    *3:                  type[C3] promotion[4] demotion[2]
> latency[085]
> > usage[00000819]
> >     4:                  type[C3] promotion[-] demotion[2]
> latency[185]
> > usage[00000000]
> >
> > It appears the demotion from C4 is to C2, when one would expect C3.
> 
> Actually, this was on purpose: I think we want to leave C3-type sleep
> quickly to advance bus master activity...

The hardware transitions us from C3 to C0 automatically, and retires the
bus master activity automatically.

The software bookeeping here is only to decide what to enter
the next time we enter idle.

I agree that the promote/demote algorithm needs some work, particularly
its tracking of bus master activity, and system busy-ness rather than
just idleness.  But with the current scheme, I believe that C4 should
demote to C3, not to C2.

thanks,
-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [PATCHES] add _CST support

[Len Brown]

Dominik,
why this one?

-module_param_named(max_cstate, max_cstate, uint, 0);
+module_param_named(max_cstate, max_cstate, uint, 0644);




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [PATCHES] add _CST support

[Len Brown]

/sys/module/processor/parameters/max_cstate

I like this.

applied.

thanks,
-Len

On Wed, 2004-12-22 at 02:22, Len Brown wrote:
> Dominik,
> why this one?
> 
> -module_param_named(max_cstate, max_cstate, uint, 0);
> +module_param_named(max_cstate, max_cstate, uint, 0644);
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/