Re: sched: deep power-saving states

From: Peter Zijlstra
Date: Wed Oct 22 2008 - 15:50:29 EST

On Wed, 2008-10-22 at 07:36 -0700, Arjan van de Ven wrote:
> On Wed, 22 Oct 2008 10:26:49 -0400
> Gregory Haskins <ghaskins@xxxxxxxxxx> wrote:
> steps, so it'll be
> > > faster)
> >
> > [Adding Peter Zijlstra to the thread]
> >
> > Ah, yes of course! That makes sense. So I have to admit I am fairly
> > ignorant of the ACPI C-state stuff, so I just read up on it. In the
> > context of what you said, it makes perfect sense to me now.
> >
> > IIUC, the OS selects which C-state it will enter at idle points based
> > on some internal criteria (TBD). All we have to do is remap the
> > cpupri "IDLE" state to something like IDLE-C1, IDLE-C2, ..., IDLE-Cn
> > and have the cpupri map get updated coincident with the pm_idle()
> > call. Then the scheduler will naturally favor cores that are in
> > lighter sleep over cores in deep sleep.
> >
> > I am not sure if this is exactly what you were getting at during the
> > conf, since it doesnt really consider deep-sleep latency times
> > directly. But I think this is a step in the right direction.
> it for sure is a step in the right direction.
> the actual exit costs are an optional parameter in this sense,
> the steps between C states are non-linear (more like exponential)
> so knowing the actual numbers could be used. but even if you don't
> use it, it still makes sense and is a very good first order behavior.

This still leaves us with the worst case IRQ response as given by the
deepest C state. Which might be un-desirable.

jcm was, once upon a time, working on dynamically changing the idle
routine, so that people who care about wakeup latency can run idle=poll
while their application runs, and the acpi C state stuff when nobody

This could of course then be tied into the PM QoS stuff Mark has been

Fact of life is, for some RT apps, anything but idle=poll is too much.

But yes, when C states are in play, it makes sense to try and wake a cpu
that's not deep over a very deep idle one.
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