Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
On Mon, Nov 11, 2013 at 12:08:49PM -0500, Phillip Susi wrote: No, I did not tune my system; I fixed the kernel so that userspace's activities do not start those disks. So, umm, implementing things in kernel to facilitate userland is great but please don't try to work around userland from kernel. It may be easy now but inevitably becomes a maintenance burden where we don't have much visibility into what userland is depending on. If a certain feature needs cooperation from userland, update userland accordingly. Thanks. -- tejun -- 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
Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/2013 7:15 AM, Tejun Heo wrote: On Mon, Nov 11, 2013 at 12:08:49PM -0500, Phillip Susi wrote: No, I did not tune my system; I fixed the kernel so that userspace's activities do not start those disks. So, umm, implementing things in kernel to facilitate userland is great but please don't try to work around userland from kernel. It may be easy now but inevitably becomes a maintenance burden where we don't have much visibility into what userland is depending on. If a certain feature needs cooperation from userland, update userland accordingly. udisks already cooperates by checking the power status before issuing more commands that would cause the drive to spin up. I suppose I could have added a sysfs flag exposing the sleep state and had userspace check that first, but it seems silly to add a whole new ABI and to check the power state rather than simply fixing the existing command to not wake the disk in order to tell userspace what we already know using a code path we already have. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsF61AAoJEI5FoCIzSKrwMvEH/3IOti/mKMvwm6b0ie3+knMT QLDPuq7K/7qkbHPuSD/Bm2OwJR69SRFYSUYLpLL/u8r1JAgRKJJx1YywFgpmRJm9 43bE+R3uXhpYxSy5zf0s8T1VbNalWWVZKjfrrXjJic+H37y0E/lZcUtq8fSPnNu9 xNXLZ2/dkmWbAw+zu2Zszao3zPeYtP3bqhYa6HFZYDKxFEl4IPg9uKnQ9rAq7D/Y /WtqOlckSqWdPSLKbQh3nbEd9dvdIqEx2wuqK8jthoHR0+HFoAGRqRHY6PKLKal5 bnxl7T8Wr6dRlb13vZZy6TwHU6HRxK6w9vCmRhSg04hHvtA8q2DmDM5Go+4PZEg= =w2m9 -END PGP SIGNATURE- -- 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
Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/2013 3:33 PM, Todd E Brandt wrote: sd_resume patch (2/2): On resume, the SD driver currently waits until the block driver finishes executing a disk start command with blk_execute_rq. This patch changes the sd_resume callback to use blk_execute_rq_nowait instead, which allows it to return immediately, thus allowing the Can another request in the queue race with the start/stop command and possibly beat it to dispatch? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlhtuAAoJEI5FoCIzSKrwgJ0H/ioXLuLHh4aJ3ZNs9LZ3gloA hQb9bTbUOFpC2HM0GpWntNs9V1KXKha7zqiW7alqmmiaUor7mN8CoVILIrwgEe10 9Fd8z0DNBjCM+BdhdSO1g2opjMYif9ID74E/nA4tP3cXV2TiPjax/lF861iirEAl xaK5WdI7Ua5qbpIc1Xr6t8EbH1DSwEbiFOkN5HGs2ldFWB+f3jTRMZiGwh2RhUzV OZt2UKIsCAhwO6opnUPJ3Vv4IHQR248uijGxcuy5KDERVbKtfz8If6CG43FVdSr/ c59AEXgUFtvPm/J9DRO/rVO7Dp2e+DTwJ67Mx9TDqtcKwuRxzsdaxn1yJEXoZfk= =IOxx -END PGP SIGNATURE- -- 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
Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
500ms is actually quite alot when you compare it with android or iOS, or even with other subsystems like USB. USB is the second worst offender after SATA disks and it tends to take around 600ms for most standard systems with an onboard webcam, and with other devices plugged in ever longer. I think we should optimize out every millisecond we can. You mentioned that you tuned your system to remove all cases that trigger non-essential disk wakeups, and that works great for you, but it won't help anyone using fedora or OpenSUSE or Yocto, etc. And even if you could formallize your changes to Ubuntu to create a fully optimized user space, you're still at the mercy of the user's install choices, which can quickly throw a wrench in the works. On Sat, Nov 09, 2013 at 03:59:04PM -0500, Phillip Susi wrote: -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/2013 11:59 AM, Todd E Brandt wrote: 500ms is actually quite alot when you compare it with android or iOS, or even with other subsystems like USB. USB is the second worst offender after SATA disks and it tends to take around 600ms for most standard systems with an onboard webcam, and with other devices plugged in ever longer. I think we should optimize out every millisecond we can. I think you missed my point: if the disk is going to be started in 9000ms vs 8500ms, it doesn't make much difference, and I think in practice the difference will be less than that. I don't think it is worth requiring that all disks start up to save a few percent in the cases where the disk is required ( and I'm not clear that there even are any such cases ). You mentioned that you tuned your system to remove all cases that trigger non-essential disk wakeups, and that works great for you, but it won't help anyone using fedora or OpenSUSE or Yocto, etc. And even if you could formallize your changes to Ubuntu to create a fully optimized user space, you're still at the mercy of the user's install choices, which can quickly throw a wrench in the works. No, I did not tune my system; I fixed the kernel so that userspace's activities do not start those disks. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSgQ8hAAoJEJrBOlT6nu75c04H/2ej9NzdyrWkuPv2SLGgb51Y iBmeAkJEoFXwgu0UCZ2Ty3dpUkW7jcRiKKv5q8d1Anj4eGFIpx+CjUptCE3MCs1w PWQm7uB6+DgOhj3aqF9DulBx0Yp3+gISwOTXYLAIirIReE4Vk904ZuYHo4IvJmug vbk4p6n5iGLMqV/QFsymPoOFtUzKQPHj4YDL3Piu0fse8AOIHk5BJtmmtj1YbAck oAsMIYz6UQZ2tXpzxcy1ISgZYUO8k6CcrXg8WE2ws9gZLNJtBHniLC1t2VCE10KF BSzP+tgN+Glbk+HyJUuwjALa/CkFk9FKQJT8LJQfn0rRhjku/vZXsZoFgCQiIx0= =THLl -END PGP SIGNATURE- -- 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
Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
-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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND v2 0/2] SATA disk resume time optimization
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. 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. 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. Ultimately I would be happy if either solution were accepted though, because this is a serious performance problem that needs to be addressed in some way. On Wed, Nov 06, 2013 at 08:53:11PM -0500, Phillip Susi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/17/2013 03:33 PM, Todd E Brandt wrote: The essential issue behind hard disks' lengthy resume time is the ata port driver blocking until the ATA port hardware is finished coming online. So the kernel isn't really doing anything during all those seconds that the disks are resuming, it's just blocking until the hardware says it's ready to accept commands. Applying this patch set I have been working in a similar direction and have patches to follow. Instead of backgrounding the start in sd_resume, I have removed it entirely, and background the resume at the ata port layer, as well as avoid resuming Power on in Standby disks entirely. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSevKEAAoJEJrBOlT6nu75FFkIAL8mwXOuuNvY5GoppHVMcweC EOBz6t2Xmc/TsGYr9u4kRVXbf3G0trSM9dj/XSJ6p+Dj/su/vJ69yKxp7sUPidgz zqjfKlG+myMQIaAO+tPGXvMcmT74BXjgjobZw2lUyLyRPLD9elDGmrDA5ZXZ+hiz hzSx4gOC57j+sK/pmoZ7U/CWeWYEYQ+J9xBXm0hzbBbSTjpzVsR0T+7xU+WVkeX0 Ox++FFBZp2b1xJgaREurRv1mORx/GJ+PfSETb49P5BWaWW+QVwOEhWOX/JQNc/Pp ANJmttP4WPvlRV0X3hD6FvAYSnu1qbwwGOiP/j5g7mklyfm5alA0jcuahc1w5tI= =9KhA -END PGP SIGNATURE- -- 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
[PATCH/RESEND v2 0/2] SATA disk resume time optimization
The essential issue behind hard disks' lengthy resume time is the ata port driver blocking until the ATA port hardware is finished coming online. So the kernel isn't really doing anything during all those seconds that the disks are resuming, it's just blocking until the hardware says it's ready to accept commands. Applying this patch set allows SATA disks to resume asynchronously without holding up system resume, thus allowing the UI to come online much more quickly. There may be a short period after resume where the disks are still spinning up in the background, but the user shouldn't notice since the OS can function with the data left in RAM. The patch set has two parts which apply to ata_port_resume and sd_resume respectively. Both are required to achieve any real performance benefit, but they will still function independantly without a performance hit. ata_port_resume patch (1/2): On resume, the ATA port driver currently waits until the AHCI controller finishes executing the port wakeup command. This patch changes the ata_port_resume callback to issue the wakeup and then return immediately, thus allowing the next device in the pm queue to resume. Any commands issued to the AHCI hardware during the wakeup will be queued up and executed once the port is physically online. Thus no information is lost. sd_resume patch (2/2): On resume, the SD driver currently waits until the block driver finishes executing a disk start command with blk_execute_rq. This patch changes the sd_resume callback to use blk_execute_rq_nowait instead, which allows it to return immediately, thus allowing the next device in the pm queue to resume. The return value of blk_execute_rq_nowait is handled in the background by sd_resume_complete. Any commands issued to the scsi disk during the startup will be queued up and executed once the disk is online. Thus no information is lost. -- 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
