On Tue, 21 Jan 2014, Dan Williams wrote: > On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 17 Jan 2014, Dan Williams wrote: > > > >> I think it's a bit of an interface surprise to have pm_runtime disable > >> have side effects only for scsi_disk devices. I think lazy_resume > >> needs to be an explicit attribute of the disk. For ata devices any > >> command wakes up the drive. Perhaps we could simply do the same for > >> scsi devices. In lazy_resume mode flag the device as "needs spinup" > >> at sd_resume time and schedule it when a command arrives. > > > > What you have just described is essentially what runtime PM does. > > Deliberately so... > > > There's no need to implement it any other way. And this explains why > > disabling runtime PM would also disable lazy resume. > > 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. That's why I proposed it. What are you getting at? > 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. None of my posts in this email thread have required the disk to be in runtime suspend prior to the system suspend. 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
