Re: [RFC] maximum latency tracking infrastructure

[Andi Kleen <ak@suse.de>]

Jesse Barnes <jbarnes@virtuousgeek.org> writes:

> On Thursday, August 24, 2006 2:20 pm, Arjan van de Ven wrote:
> > Jesse Barnes wrote:
> > > On Thursday, August 24, 2006 10:41 am, Arjan van de Ven wrote:
> > >> The reason for adding this infrastructure is that power management
> > >> in the idle loop needs to make a tradeoff between latency and power
> > >> savings (deeper power save modes have a longer latency to running
> > >> code again).
> > >
> > > What if a processor was already in a sleep state when a call to
> > > set_acceptable_latency() latency occurs?
> >
> > there's nothing sane that can be done in that case; any wake up
> > already will cause the unwanted latency! A premature wakeup is only
> > making it happen *now*, but now is as inconvenient a time as any...
> > (in fact it may be a worst case time scenario, say, an audio
> > interrupt...)
> 
> Depends on what's going on.  What if you have a two socket machine, and 
> one CPU is in C3 when the latency setting occurs?

I didn't think there were currently any multi socket machines with C3 
support? The best you get is dual core.

> Shouldn't you wake it 
> up and prevent it from going that deep again?  But you're right, you 
> won't necessarily improve anything...

Generally there are so many events that wake up CPUs that the case is pretty 
academic -- all CPUs will eventually wake up in a reasonable time
(before your driver initialization finished likely) and then follow
the new latency settings.

Maybe at some point if all the idle breaking events in Linux have been
fixed up it might be a problem, but I think that's a long time off.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/