From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH v5 3/3] scsi: async sd resume Date: Mon, 10 Mar 2014 16:43:14 -0400 Message-ID: <20140310204314.GH25290@htj.dyndns.org> References: <1394247126.10864.3.camel@dwillia2-mobl2.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-qc0-f174.google.com ([209.85.216.174]:35083 "EHLO mail-qc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754708AbaCJUnT (ORCPT ); Mon, 10 Mar 2014 16:43:19 -0400 Content-Disposition: inline In-Reply-To: <1394247126.10864.3.camel@dwillia2-mobl2.amr.corp.intel.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Dan Williams Cc: Alan Stern , JBottomley@Parallels.com, Len Brown , linux-scsi@vger.kernel.org, Phillip Susi , linux-ide@vger.kernel.org, Todd Brandt On Fri, Mar 07, 2014 at 06:52:06PM -0800, Dan Williams wrote: > From: Dan Williams > > 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. > > Inspired by Todd's analysis and initial proposal [2]: > https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach The only thing which is a bit concerning is that this doesn't have any throttling mechanism for simultaneous wakeups. Would this be able to blow up the PSU if used on a machine with a lot of spindles? Thanks. -- tejun