Re: [PATCH V2 0/4] introduce device async actions mechanism

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

 



On Wed, 2009-08-05 at 01:33 +0800, Alan Stern wrote:
> On Tue, 4 Aug 2009, Rafael J. Wysocki wrote:
> 
> > Not only that.  I'd like to simplify the design, because IMO using one async
> > domain would be much more straightforward than using multiple ones.
> 
> > If I understand the async framework correctly, the domains are only used for
> > synchronization, ie. if you want to wait for a group of async operations to
> > complete, you can put them all into one domain and then call
> > async_synchronize_full_domain() to wait for them all together.
> > 
> > You don't need multiple domains to run multiple things in parallel.
> 
> There's a basic confusion going on here.
> 
> Rui is using "async domain" to mean a collection of devices which 
> will be suspended or resumed serially.  Different domains run in 
> parallel.
> 
> Rafael is using "async domain" to mean a collection of devices which 
> will be suspended or resumed in parallel.  Different domains run 
> serially.
> 
cool, thanks for stating the confusion so clearly, Alan. :)

Hi, Rafael,

maybe there is still some confusions about my proposal.

I re-read kernel/async.c file, and notice that Arjan calls the domain as
*_synchronization_* domain. sorry I use the wrong word before.

And I use the synchronization domains just to keep devices dependency.

First, the general idea is to suspend/resume those slow devices in
parallel. So we don't suspend/resume them synchronously, instead, we
move these actions to the global domain.

Then, I found that these actions can not be run asynchronously because
they depend on other devices.
For example, sd depends on SATA controller, we should make sure the PM
callbacks of sd and ahci sata controller are run serially. so a
synchronization domain is created for them.
This is how multiple synchronization domains come from in this proposal.

thanks,
rui

> Once that is cleared up, you should be able to communicate a little 
> better...  :-)
> 
> Alan Stern
> 

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux