Re: [GIT PULL] PM updates for 2.6.33

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 6 Dec 2009, Linus Torvalds wrote:

> 	# Phase one: walk the tree synchronously, starting any
> 	# async work on the leaves
> 	suspend_prepare(root)
> 	{
> 		for_each_child(root) {
> 			// This may take the parent lock for
> 			// reading if it does something async
> 			suspend_prepare(child);
> 		}
> 		suspend_prepare_one_node(root);
> 	}
> 
> 	# Phase two: walk the tree synchronously, waiting for
> 	# and finishing the suspend
> 	suspend(root)
> 	{
> 		for_each_child(root) {
> 			suspend(child);
> 		}
> 		// This serializes with any async children started in phase 1
> 		write_lock(root->lock);
> 		suspend_one_node(root);
> 		write_unlock(root->lock);
> 	}
> 
> and I really think this should work.

> No complex concepts. No change to existing tested drivers. No callbacks, 
> no flags, no nothing. And a pretty simple way for a driver to decide: I'll 
> do my suspends asynchronously (without parent drivers really ever even 
> having to know about it).
> 
> I dunno. Maybe I'm overlooking something, but the above is much closer to 
> what I think would be worth doing.

You're overlooking resume.  It's more difficult than suspend.  The
issue is that a child can't start its async part until the parent's
synchronous part is finished.

So for example, suppose the device listing contains P, C, Q, where C is
a child of P, Q is unrelated, and P has a long-lasting asynchronous
requirement.  The resume process will stall upon reaching C, waiting
for P to finish.  Thus even though P and Q might be able to resume in
parallel, they won't get the chance.

An approach that handles resume well can probably be adapted to handle 
suspend too.  The reverse isn't true, as this example shows.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux