Re: Re: [PATCHES] add _CST support

Len Brown
2004-12-23T05:30:55Z

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