Re: Disk spin-up optimization during system resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 21 Jan 2014, Phillip Susi wrote:

> On 1/21/2014 5:12 AM, Dan Williams wrote:
> > The need is to avoid tying rpm and dpm ops together in surprising
> > new ways that require userspace to change if it wants to keep the
> > default behavior of hiding resume latency as much as possible.  A
> > lazy_resume knob vs changing the default let's the few setups that
> > care set the power-up in standby mode.  It should also "perform"
> > better given it does not require the disk to be runtime suspended
> > prior to system suspend, it will unconditionally resume on demand.
> 
> The more I think about it the more I agree that the new knob is
> needed.  If the user wants runtime pm but without the lazy system
> resume, switching off runtime pm prior to suspend would needlessly
> force the disk to spin up if it is already in standby, then right back
> down again.  At least, that's how rpm is currently implemented, which
> is something else I found odd about it.  Why can't you disable auto
> suspend, but still be able to manually suspend or leave an already
> suspended device asleep?

The user is in charge of enabling or disabling runtime PM.  But the
kernel chooses whether or not runtime PM will use autosuspend -- the
user doesn't get to decide that.  It is determined by how the driver is
written.

Thus, if a device's driver chooses to use autosuspend, the only way the 
user can prevent the device from going into runtime suspend is by 
disabling it for runtime PM altogether (which means waking up the 
device if it is already suspended).

However, there is a compromise.  The user gets to select the
autosuspend delay.  If that delay is set to a very large value, it will
effectively prevent autosuspends from occurring, without causing an
already-suspended device to resume right away.  (On the other hand, it 
would not prevent a lazy resume.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux