-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/08/2013 08:20 PM, Todd E Brandt wrote: > I tested your patches and they do function. We tried a similar > approach a few months back where instead of waking the scsi disks > we just set them all to runtime_suspended and skipped the resume. > Then we let them be awakened later by read/write access just as you > have. It's a really tempting approach, in theory, since you're > saving both time and power by only waking those disks you know you > need. But in practice I've found that userspace doesn't play nice. I've just about gotten rid of all instances of user space waking the disks on my system. The one I have left to do is to fake the IDENTIFY DEVICE command using the cached identity info to satisfy a script that tries to set the APM mode of the disk after resume. If I disable that script, my extra disks stay asleep and Xwindows fires up nice and fast. > In my experience the user layer almost always manages to wake up > every mounted disk after resume, even if you didn't deliberately > use them prior to suspend. The accesses can come from the file > manager doing a scan after resume, or from any number of apps > running on the system that decide they need to get even the > smallest piece of information from the disks. A simple space check > will wake them up. By simple space check I assume you mean df? The superblocks easily fit in the cache so that shouldn't generate any IO. > Thus when you leave all the disks stopped, user space ends up > triggering a traffic jam when the OS wakes back up, which makes > disk access take even longer. > > My patch works very similarly to yours but just triggers an > asynchronous wakeup to all the disks in anticipation of userspace's > needs. We've tested it pretty heavily on ubuntu machines of all > types and it's done well. I don't think the wakeup is needed since ( ata ) disks normally wake up on their own unless you enable power up in standby and pro-actively initiating the wakeup only buys you maybe 500ms or less? What is that compared to a typical 10 second startup time? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSfqIUAAoJEJrBOlT6nu75v3sH/R374d/Sgx3DB0DVGgDch3jA ZlR4eb5x5umw2CApGE0jbbj91/330Z5uxgr76tn6/nSRftDJ5ZgLc6dBTF1VwX4q fqxKgNY1euIARiCL4jLxiK9JfX7hB0GtknJaMRvG4JHaSP4d0Cvhr0sbd5mpmJp7 P0TMVslJJHyIFVk0QjvisDBcFgo1onBkbVnX6B5Z6mPZXhAd+WCA3CJfiHnAK7t+ mINmlTBXnZQFXLXY2rDrmZEUCLFfTqtlprkAuGdlfXsMVYBTD31notuZ74Xbv7C7 vBJLiQ6b7dyF8eqcHoc49qqNO1n38nhRmYhIOSYgsyRFhECjVms5/mfEj9UBkiY= =iDTY -----END PGP SIGNATURE----- -- 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
