Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH 0/6] PM: Asynchronous suspend and resume of devices | Date | Thu, 27 Aug 2009 23:18:19 +0200 |
| |
On Thursday 27 August 2009, Alan Stern wrote: > On Wed, 26 Aug 2009, Rafael J. Wysocki wrote: > > > Hi, > > > > The following patches introduce a mechanism allowing us to execute device > > drivers' suspend and resume callbacks asynchronously during system sleep > > transitions, such as suspend to RAM. > > > > The idea is explained in the changelogs of the first two patches. > > > > Comments welcome. > > I've been terribly busy and haven't had a chance to look at this. The > earlier version seemed to have a bunch of mutual-exclusion issues; are > they resolved now?
Please be more specific.
> There were also some problems involving unsafe iteration over the dpm_list > -- remember that devices can be unregistered at any time, not just while > they are suspending or resuming.
Not at the time we're holding dpm_list_mtx, though.
I don't think there are any unsafe iterations over dpm_list in the patches.
> When a device finishes, instead of having the async thread look for > another device to work on, I think it would be better to have the > thread check the dependents of the current device. Those which are > now ready can be added to a "device-ready" list, which is used to > direct the actions of new async threads.
Actually, I wanted to avoid adding such a list, because that would be duplicating of the async framework's actions, to some extent. Yes, we can duplicate the async framework just for the suspend/resume needs. No, I don't think it's worth it.
BTW, the patches have been tested on a dual-core box and I haven't seen any problems with them so far. Also, the testing shows that the waiting for devices with unsatisfied dependencies is almost eliminated (on my test box it happens 4-8 times during the entire suspend-resume cycle).
Thanks, Rafael
| |