Re: sched: deep power-saving states

[Peter Zijlstra]

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
cares.

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

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/