On Tuesday 18 August 2009, Alan Stern wrote: > On Mon, 17 Aug 2009, Rafael J. Wysocki wrote: > > > On Wednesday 12 August 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 [1/1] patch > > > message. > > > > Changes: > > > > * Added [1/7] that fixes kerneldoc comments in drivers/base/power/main.c > > (this is a 2.6.32 candidate). > > > > * Added [2/7] adding a framework for representing PM link (idea described > > in the patch message). > > > > * [3/7] is the async resume patch (idea described in the patch message). > > > > * [4/7] is the async suspend patch. > > > > * [5/7] - [7/7] set async_suspend for devices in a few selected subsystems. > > > > The patches have been tested on HP nx6325. > > > > Comments welcome. > > I'm not sure about the design of these things. How much do we care > about wasting memory? Not much. > Your scheme allocates six pointers for every dependency, plus four pointers > for every device. Yes, it does. > It's possible to reduce this considerably, especially if the parent-child > dependencies aren't stored explicitly. Yes, at the expense of increased complexity and reduced performance. > If you decide to keep this scheme, you should make pm_link_add() check > for duplicate dependencies before adding them. That's correct. > Also, I think a better approach to the async execution would not > require adding a struct completion to each device and making each async > thread wait for the completion to be signalled. Instead, have a single > master thread (i.e., the thread doing the suspend) monitor the > dependencies and have it farm the devices out to async threads as they > become ready to be suspended or resumed. Do you mean that the master thread should check the dependencies _before_ executing, for example, __device_resume() and execute it asynchronously only if they are already satisfied? In that case we might lose the opportunity to save some time. For example, assume devices A and B depend on C. Say that normally, A would be handled before B, so if C hasn't finished yet, the A's callback will be executed synchronously. Now, if both A and B take time T to complete the callback and C finishes dT after we've called A synchronously, we'll lose the chance to save T - dT by handling A and B in parallel. The master thread might chose another device for asynchronous execution, but then it should revisit A and B and that still is going to be suboptimal time-wise in some specific situations (eg. A and B are the last two devices to handle). > Finally, devices that don't have async_suspend set should implicitly > depend on everything that comes after them (for suspend) or before them > (for resume) in the device list. They do, through dpm_list. 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
