Re: [PATCH] Hard disk S3 resume time optimization

[Tejun Heo <tj@kernel.org>]

Hello,

First of all, if at all possible, please try to fill the message to 80
columns, preferably a bit narrower than that.  Most email clients can
do it without you knowing.

> [The Problem]
> The vast majority of time spent in S3 resume is consumed by the ATA
> subsystem as it resumes the computer's hard drives. For large hard
> disks this time can be upwards of 10 seconds, which makes S3
> suspend/resume too costly to use frequently. This time needs to be
> reduced. I've written a blog entry describing the details at this
> url:
> https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-worst-offender

Yeah, this sucks.  Years back, there were several releases in which
libata implemented its own supsend / resume mechanism mostly from the
exception handler, which was fully asynchronous.  It later got
reimplemented in terms of SCSI suspend/resume and lost that, which is
a bummer.

> [Proposed Solution]
> I've implemented a potential solution in this patch, which
> effectively reduces total resume time from multiple seconds to less
> than 700ms. The idea is to allow the ATA/SCSI subsystems to resume
> asynchronously without blocking system resume completion. The
> dpm_resume call currently waits for all asynchronous devices to
> finish resuming before it gives control back to the user. But in the
> case of ATA/SCSI we can give control back immediately, since the
> hard disks won't be needed immediately in lieu of RAM and cache.

Yeap.

So, while I agree about the problem and the solution seems to be
headed the right way of making SCSI suspend/resume asynchronous,
what's going on with patch splitting, submission format and comments?
Please read up on patch submission (there gotta be enough people in
OSTC to point you to the right direction) and retry.

Thanks.

-- 
tejun