Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization

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

 



-----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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux