Re: [GIT PULL] PM updates for 2.6.33

[Arjan van de Ven <arjan@infradead.org>]

On Sun, 6 Dec 2009 21:57:55 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> Now, the problem remains that when you walk the device tree starting
> off all these potentially asynchronous events, you don't want to do
> that serialization part (the "parent suspend") as you walk the tree -
> because then you would only ever do one single level asynchronously.
> Which is why I suggested splitting the suspend into a "pre-suspend"
> phase (and a "post-resume" one). Because then the tree walk goes from

> I dunno. Maybe I'm overlooking something, but the above is much
> closer to what I think would be worth doing.

with what you're describing I suspect the current async function calls
could be used;
in the first tree walk, the drivers do an async_schedule() of the
things they want done asynchronous;
all the core then needs to do is a full synchronization step between the
two tree walks... and we get pretty much all the benefits without
needing the read-then-write-lock primitive for synchronization.

alternative would be to do the synchronization in the part where we
know there's a dependency (like your lock is doing); 
but instead of a lock we could store the async cookie there; and just
wait on that in the 2nd phase....  this would be more finegrained, and
an optimization from the "global synchronize"... but I'm not sure it'll
be worth it in practice; it will if there's significant cost in various
parts of the tree AND in the 2nd run; if the 2nd run is cheap in
general, you're not going to get real extra parallelism at the price of
more complexity.
-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org