lkml.org 
[lkml]   [2009]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 0/7] PM: Asynchronous suspend and resume (updated)
    Date
    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


    \
     
     \ /
      Last update: 2009-08-18 21:59    [W:3.068 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site