From: Tejun Heo <tj@kernel.org>
To: Maksim Rayskiy <maksim.rayskiy@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
linux-pm@lists.linux-foundation.org, linux-scsi@vger.kernel.org
Subject: Re: [linux-pm] [RFC] Deferred disk spinup during system resume
Date: Fri, 31 Dec 2010 12:27:32 +0100 [thread overview]
Message-ID: <20101231112732.GG18831@htj.dyndns.org> (raw)
In-Reply-To: <AANLkTikLn7VyB+TJMz=GGTHKSHg+9feQ9bje+KS3pD3k@mail.gmail.com>
On Thu, Dec 30, 2010 at 04:49:29PM -0800, Maksim Rayskiy wrote:
> >> 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
next prev parent reply other threads:[~2010-12-31 11:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-30 19:40 [RFC] Deferred disk spinup during system resume Maksim Rayskiy
2010-12-30 22:46 ` [linux-pm] " Rafael J. Wysocki
2010-12-31 0:49 ` Maksim Rayskiy
2010-12-31 11:27 ` Tejun Heo [this message]
2010-12-31 11:45 ` Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2011-01-07 1:17 maksim.rayskiy
2011-01-07 3:16 ` Jeff Garzik
2011-01-07 3:46 ` Maksim Rayskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101231112732.GG18831@htj.dyndns.org \
--to=tj@kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-scsi@vger.kernel.org \
--cc=maksim.rayskiy@gmail.com \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox