On Fri, Jan 17, 2014 at 7:18 PM, Phillip Susi <ps...@ubuntu.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/17/2014 05:17 PM, Dan Williams wrote: >> Well, "at all" is overstating it. The system was idle and now >> it's being woken up to do some work. Inactivity timers are >> invalidated and now the decision becomes minimize access latency, >> or lazily wake up. > > Sure, but that work may or may not involve disk access. Think of a > laptop you are using to watch a video on youtube. You need to get up > for a minute so you suspend, come back, and continue watching... no > need for disk IO just because you paused for a few minutes. For a > single disk system you may argue that it is likely the disk will be > needed, but for multiple disk systems, that probability goes down. > >>> It puts needless wear and tear on disks. >> >> I'm not sure spin up cycles are predictive of drive failure? > > Drive makers rate them to handle only so many start/stop cycles before > they fail, which is why SMART keeps track of the count. Any time you > move mechanical parts, they wear out.
They also recommend maximum intervals of spin down time. Mind you its on the order of weeks, but spinning up the drive help keeps the bearing lubricant evenly distributed. What I was getting at is do these patches have a measurable impact on drive lifetime? For example how many spin ups is this saving vs deferring in your setup. I buy the power saving impact, but wearing out the drive prematurely is harder to accept without data. >> I'm not arguing about the attach rate of HDDs in shipping systems, >> I'm asking what is the system suspend / resume frequency of such >> systems and is it worth carrying that complexity in the kernel and >> injecting unnecessary resume latency for what amounts to a niche >> use case. > > It doesn't add any latency for an SSD, or even an ATA HDD that does > not have PuiS enabled. SCSI disks are more likely to be in larger > systems where it is more likely that at least some of the drives won't > be accessed soon, and if you really want to avoid the latency, then > you can configure your user space pm scripts to disable runtime pm > prior to suspend to get the old behavior back. > Larger systems are less likely to ever sleep. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
