lkml.org 
[lkml]   [2013]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] don't wait on disk to start on resume
    On Fri, 1 Feb 2013, Aaron Lu wrote:

    > Hi Derek,
    >
    > On 12/21/2012 12:35 PM, Derek Basehore wrote:
    > > We no longer wait for the disk to spin up in sd_resume. It now enters the
    > > request to spinup the disk into the elevator and returns.
    > >
    > > A function is scheduled under the scsi_sd_probe_domain to wait for the command
    > > to spinup the disk to complete. This function then checks for errors and cleans
    > > up after the sd resume function.
    > >
    > > This allows system resume to complete much faster on systems with an HDD since
    > > spinning up the disk is a significant portion of resume time.
    >
    > An alternative way of possibly solving this problem from PM's point of
    > view might be:
    > 1 Set both ata port and scsi device's runtime status to RPM_SUSPENDED
    > in their system suspend callback;
    > 2 On resume, do nothing in their system resume callback;
    > 3 With request based runtime PM introduced here:
    > http://thread.gmane.org/gmane.linux.power-management.general/30405
    > When a request comes for the HDD after system resume, both the ata
    > port and the scsi device will be runtime resumed, which involves
    > re-initialize the ata link(in ata port's runtime resume callback) and
    > spin up the HDD(in sd's runtime resume callback).
    >
    > To make HDD un-affetcted by runtime PM during normal use, a large enough
    > autosuspend_delay can be set for it.
    >
    > Just my 2 cents, I've not verified or tried in any way yet :-)

    It's a good idea. The problem is that it won't work if CONFIG_PM_SLEEP
    is enabled but CONFIG_PM_RUNTIME isn't.

    Alan Stern



    \
     
     \ /
      Last update: 2013-02-01 17:01    [W:3.664 / U:0.392 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site