From: Sergei Shtylyov <sshtylyov@mvista.com>
To: Derek Basehore <dbasehore@chromium.org>
Cc: JBottomley@parallels.com, jgarzik@pobox.com,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] don't wait on disk to start on resume
Date: Sat, 22 Dec 2012 18:32:19 +0400 [thread overview]
Message-ID: <50D5C473.2030902@mvista.com> (raw)
In-Reply-To: <1356064540-17414-1-git-send-email-dbasehore@chromium.org>
Hello.
On 21-12-2012 8:35, Derek Basehore wrote:
> We no longer wait for the disk to spin up in sd_resume. It now enters the
> request to spinup the disk into the elevator and returns.
>
> A function is scheduled under the scsi_sd_probe_domain to wait for the command
> to spinup the disk to complete. This function then checks for errors and cleans
> up after the sd resume function.
> This allows system resume to complete much faster on systems with an HDD since
> spinning up the disk is a significant portion of resume time.
> Signed-off-by: Derek Basehore <dbasehore@chromium.org>
> ---
> drivers/scsi/sd.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++++---
> drivers/scsi/sd.h | 9 ++++
> 2 files changed, 108 insertions(+), 7 deletions(-)
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 7992635..2fe051f 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
[...]
> @@ -3087,20 +3089,110 @@ done:
> return ret;
> }
>
> +/*
> + * Callback function for when the request that starts the disk completes. Passed
> + * into blk_execute_rq_nowait in sd_resume.
> + */
> +static void sd_end_start_rq(struct request *rq, int error)
> +{
> + struct completion *waiting = rq->end_io_data;
> +
> + rq->end_io_data = NULL;
> + /*
> + * Set the end_io_data to NULL before calling complete. This (with
> + * sd_resume async) ensures that it is set to NULL before we call
> + * blk_put_request.
> + */
Shouldn't this comment precede the previous statement?
> + complete(waiting);
> +}
[...]
> static int sd_resume(struct device *dev)
> {
> struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
> - int ret = 0;
> + struct scsi_device *sdp = sdkp->device;
> + struct resume_async_struct *resume = NULL;
> + struct request *req;
> + unsigned char cmd[6] = { START_STOP }; /* START_VALID */
>
> - if (!sdkp->device->manage_start_stop)
> - goto done;
> + if (!sdkp->device->manage_start_stop) {
> + scsi_disk_put(sdkp);
> + return 0;
> + }
>
> sd_printk(KERN_NOTICE, sdkp, "Starting disk\n");
> - ret = sd_start_stop_device(sdkp, 1);
>
> -done:
> - scsi_disk_put(sdkp);
> - return ret;
> + cmd[4] |= 1; /* START */
> +
> + if (sdp->start_stop_pwr_cond)
> + cmd[4] |= 1 << 4; /* Active */
> +
> + if (!scsi_device_online(sdp))
> + return -ENODEV;
> +
> + resume = kzalloc(sizeof(struct resume_async_struct), GFP_NOIO);
> + if (!resume)
> + return DRIVER_ERROR << 24;
> +
> + req = blk_get_request(sdp->request_queue, 0, __GFP_WAIT);
> + if (!req)
> + return DRIVER_ERROR << 24;
> +
> + resume->req = req;
> + resume->sdkp = sdkp;
> + init_completion(&resume->wait);
> +
> + req->cmd_len = COMMAND_SIZE(cmd[0]);
> + memcpy(req->cmd, cmd, req->cmd_len);
> + req->sense = resume->sense;
> + req->sense_len = 0;
Not SCSI_SENSE_BUFFERSIZE?
> + req->retries = SD_MAX_RETRIES;
> + req->timeout = SD_TIMEOUT;
> + req->cmd_type = REQ_TYPE_BLOCK_PC;
> + req->cmd_flags |= REQ_QUIET | REQ_PREEMPT;
> + req->end_io_data = &resume->wait;
> +
> + async_schedule_domain(sd_resume_async, resume, &scsi_sd_probe_domain);
> + /*
> + * don't wait here for the disk to spin up, since we can resume faster
> + * if we don't. Cleanup and checking for errors is done the the
s/the the/in the/
WBR, Sergei
next prev parent reply other threads:[~2012-12-22 14:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 4:35 [PATCH 1/2] don't wait on disk to start on resume Derek Basehore
2012-12-21 4:35 ` [PATCH 2/2] ata: don't wait " Derek Basehore
2012-12-22 14:32 ` Sergei Shtylyov [this message]
2013-01-31 22:00 ` [PATCH 1/2] don't wait on disk to start " dbasehore .
2013-01-31 22:27 ` James Bottomley
2013-01-31 22:32 ` dbasehore .
2012-12-23 11:49 ` James Bottomley
2013-01-31 22:02 ` dbasehore .
2013-01-31 22:26 ` James Bottomley
2013-02-01 11:51 ` Aaron Lu
2013-02-01 15:28 ` Alan Stern
2013-02-01 15:28 ` Alan Stern
2013-02-02 10:45 ` Aaron Lu
2013-02-02 15:09 ` Alan Stern
2013-02-02 15:09 ` Alan Stern
2013-02-03 6:23 ` Aaron Lu
2013-02-04 0:07 ` dbasehore .
2013-02-04 14:27 ` Aaron Lu
2013-02-04 8:04 ` Aaron Lu
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=50D5C473.2030902@mvista.com \
--to=sshtylyov@mvista.com \
--cc=JBottomley@parallels.com \
--cc=dbasehore@chromium.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.