On Tue, Jan 21, 2014 at 8:18 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > On Tue, Jan 21, 2014 at 7:44 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> 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? > > ? > > Yes, earlier in the thread you propose a lazy_resume knob and then > later say "there's no need to implement it any other way" referring to > runtime PM. I took that to mean there's no need to consider any other > solution besides disabling runtime PM. The source of my contention was that userspace should not need to take new action to restore historical behavior. After taking another look at the thread I see you were likely agreeing with that, but just proposing that when lazy_resume is enabled the mechanism to maintain disk spin-down is runtime PM. That makes sense. -- Dan -- 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
