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 -- 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