On Thu, Dec 30, 2010 at 04:49:29PM -0800, Maksim Rayskiy wrote:
quoted text
> >> When resuming from system suspend, scsi disks are being spun up which
> >> takes quite a lot of time (5+ seconds in my case). The spinup is done
> >> synchronously, so this time adds up to overall system resume time.
> >> Ours is an embedded platform and we are using flash-based rootfs, so
> >> there is no immediate need in harddrive after resume. What is much
> >> more important for us is to minimize time-to-full-power. To speed up
> >> resume, we would like to have an option to defer the spinup or run it
> >> in parallel with system resume. I could not find any existing
> >> mechanism to do the trick, but I might have missed something.
> >>
> >> Can anybody comment on this?
> >
> > Do you use asynchronous suspend/resume?
> >
> 
> Yes, asynchronous suspend/resume is enabled - it saves about 0.5
> second in my case. But resume blocks anyway because disk driver is
> waiting on sd_resume() to complete.
> 
> I am wondering if we could let the resume proceed while spinup is
> going on, just mark the scsi device as quiescent to block any data
> transfers.

Yeah, it was asynchronous for a while when suspend/resume were
implemented in libata proper.  It's a bit trickier to do that with sd
doing the higher level part.  Hmmm... most SATA disks spin up
automatically anyway so disabling START_STOP from sd should do the
trick.  Does the following achieve async resume?

 echo 0 > /sys/block/sdX/device/scsi_disk/h:c:i:l/manage_start_stop

The problem is that the above would also prevent the kernel from
issuing STANDBY_NOW on suspend or power down.  Maybe we should just
make start_stop_xlat schedule async EH action instead.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html