Re: Disk spin-up optimization during system resume

[Todd E Brandt <todd.e.brandt@linux.intel.com>]

On Fri, Jan 17, 2014 at 09:57:47AM -0500, Alan Stern wrote:
> On Thu, 16 Jan 2014, Todd E Brandt wrote:
> 
> > On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
> > > On Thu, 16 Jan 2014, Todd E Brandt wrote:
> > > 
> > > > > Does this plan sound reasonable to everyone?  Are there important
> > > > > aspects I haven't considered (such as interactions between the SCSI and
> > > > > ATA layers)?
> > > > > 
> > > > > Alan Stern
> > > > > 
> > > > 
> > > > Both approaches employ non-blocking resume of the scsi disks so why don't
> > > > we treat these two patch sets as parts one and two. My patch just spins
> > > > everything up but sets everything to non-blocking, so it will take care
> > > > of the most common use cases. Your patch will then fine-tune that behavior
> > > > to only spin up those disks that are actually needed. I don't think there
> > > > are any serious conflicts between the two patch sets.
> > > 
> > > Hmmm.  In your 2/2 patch, sd_resume_complete() gets called in atomic
> > > context.  I would need a process context in order to carry out a
> > > runtime resume.  Any suggestions?
> > 
> > The complete call is really just there to printk any errors and free
> > the sense buffer. Why would you want to carry out a runtime resume in
> > it?
> 
> From my earlier message:
> 
>  	Otherwise, check to see whether the disk is spinning up all
>  	by itself.  This presumably will involve issuing a TEST UNIT
>  	READY command and checking the sense data.  Maybe something
>  	different will be needed for ATA disks; I don't know.
>  
>  	If the disk is spinning, or if you can't tell, call
>  	pm_runtime_resume() to put the disk back into the
>  	RPM_ACTIVE state (and spin it up in the case where you 
>  	couldn't tell what it was doing).
> 
> As you can see, the runtime resume is carried out in the completion
> routine for the TEST UNIT READY command.  Since the command is likely
> to take a long time (Phillip said it can take up to 10 seconds for ATA
> disks), we want it to be asynchronous, like the START-STOP command.

10 seconds?! The only possible way that could happen is if the test unit
ready SCSI command actually triggered an ata port wakeup; at which point
you've already done the one thing you were trying not to do.

> 
> > > Also, I don't understand the point of your 1/2 patch.  If the whole
> > > point of that patch was to carry out the ATA port resume asynchronously
> > > ("thus allowing the next device in the pm queue to resume"), doesn't
> > > device_enable_async_suspend() already do that for you?
> > > 
> > > Alan Stern
> > > 
> > 
> > The device_enable_async_suspend call is used to set a pm flag which lets
> > the power manager know that this device can be added to the async suspend
> > queue. Basically that means that it can be suspended/resumed in parallel
> > with all the other async devices, but resume still waits for all those
> > devices to finish before completing system resume.
> 
> Correct.
> 
> > My patch makes ata port and scsi disk resume 'non-blocking' (asynchronous
> > with respect to system resume). Which means once they're called the power
> > manager pays no more attention to them and will complete system resume
> > whenever. Both the power manager and the ata subsystems call these 
> > features 'asynchronous' so it can be confusing.
> 
> I see.  That's not explained very well in the patch description -- it
> talks about going on to resume the next device on the list, but not
> about waiting for the overall system resume to finish.

I'll word it differently if I have to resubmit again, but it does assume
a working knowledge of the pm subsystem.

> 
> Alan Stern
>