aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/scsi/Kconfig
diff options
context:
space:
mode:
authorDan Williams <dan.j.williams@intel.com>2014-04-10 18:30:35 -0400
committerDan Williams <dan.j.williams@intel.com>2014-04-10 18:30:35 -0400
commit3c31b52f96f7b559d950b16113c0f68c72a1985e (patch)
tree2ae13004870a1fed2e6f9fee49111fa947cb5d06 /drivers/scsi/Kconfig
parent455c6fdbd219161bd09b1165f11699d6d73de11c (diff)
scsi: async sd resume
async_schedule() sd resume work to allow disks and other devices to resume in parallel. This moves the entirety of scsi_device resume to an async context to ensure that scsi_device_resume() remains ordered with respect to the completion of the start/stop command. For the duration of the resume, new command submissions (that do not originate from the scsi-core) will be deferred (BLKPREP_DEFER). It adds a new ASYNC_DOMAIN_EXCLUSIVE(scsi_sd_pm_domain) as a container of these operations. Like scsi_sd_probe_domain it is flushed at sd_remove() time to ensure async ops do not continue past the end-of-life of the sdev. The implementation explicitly refrains from reusing scsi_sd_probe_domain directly for this purpose as it is flushed at the end of dpm_resume(), potentially defeating some of the benefit. Given sdevs are quiesced it is permissible for these resume operations to bleed past the async_synchronize_full() calls made by the driver core. We defer the resolution of which pm callback to call until scsi_dev_type_{suspend|resume} time and guarantee that the callback parameter is never NULL. With this in place the type of resume operation is encoded in the async function identifier. There is a concern that async resume could trigger PSU overload. In the enterprise, storage enclosures enforce staggered spin-up regardless of what the kernel does making async scanning safe by default. Outside of that context a user can disable asynchronous scanning via a kernel command line or CONFIG_SCSI_SCAN_ASYNC. Honor that setting when deciding whether to do resume asynchronously. Inspired by Todd's analysis and initial proposal [2]: https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach Cc: Len Brown <len.brown@intel.com> Cc: Phillip Susi <psusi@ubuntu.com> [alan: bug fix and clean up suggestion] Acked-by: Alan Stern <stern@rowland.harvard.edu> Suggested-by: Todd Brandt <todd.e.brandt@linux.intel.com> [djbw: kick all resume work to the async queue] Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Diffstat (limited to 'drivers/scsi/Kconfig')
-rw-r--r--drivers/scsi/Kconfig3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index c8bd092fc945..02832d64d918 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -263,6 +263,9 @@ config SCSI_SCAN_ASYNC
263 You can override this choice by specifying "scsi_mod.scan=sync" 263 You can override this choice by specifying "scsi_mod.scan=sync"
264 or async on the kernel's command line. 264 or async on the kernel's command line.
265 265
266 Note that this setting also affects whether resuming from
267 system suspend will be performed asynchronously.
268
266menu "SCSI Transports" 269menu "SCSI Transports"
267 depends on SCSI 270 depends on SCSI
268 271