Re: sched: deep power-saving states

From: Arjan van de Ven
Date: Wed Oct 22 2008 - 10:07:06 EST

On Wed, 22 Oct 2008 10:05:21 -0400
Gregory Haskins <ghaskins@xxxxxxxxxx> wrote:

> Arjan van de Ven wrote:
> > On Wed, 22 Oct 2008 09:42:52 -0400
> > Gregory Haskins <> wrote:
> >
> >
> >> What I was thinking is that a simple mechanism to quantify the
> >> power-state penalty would be to add those states as priority
> >> levels in the cpupri namespace. E.g. We could substitute
> >> IDLE-RUNNING for IDLE, and add IDLE-PS1, IDLE-PS2, .. IDLE-PSn,
> >> OTHER, RT1, .. RT99. This means the scheduler would favor waking
> >> an IDLE-RUNNING core over an IDLE-PS1-PSn, etc. The question in
> >> my mind is: can the power-states be determined in a static fashion
> >> such that we know what value to quantify the idle state before we
> >> enter it? Or is it more dynamic (e.g. the longer it is in an
> >> MWAIT, the deeper the sleep gets).
> >
> > it's a little dynamic, but just assuming the worst will be a very
> > good approximation of reality. And we know what we're getting into
> > in that sense.
> >
> Ok, but if we just assume the worst case always, how do I
> differentiate between, say, IDLE-RUNNING and IDLE-PSn? If I assign
> them all to IDLE-PSn apriori its no better than the basic single IDLE
> state we support today. Or am I misunderstanding you?

eh yes I wasn't very clear; it's pre-coffee time here ;)

we know *for each C state* we go in, what its maximum latency is.
Now, that is the *maximum*; there are times where it'll be less
(there are several steps for going into a C-state hardware wise, and if
an interrupt comes in before they're all completed, getting out of it
means not having to undo ALL the steps, so it'll be faster)

Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at