From: Jeff Garzik <jeff@garzik.org>
To: Alan Cox <alan@linux.intel.com>
Cc: jeff@garzik.org.com, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org
Subject: Re: [RFC 1/4] libata: cache device select
Date: Mon, 01 Mar 2010 15:15:53 -0500 [thread overview]
Message-ID: <4B8C2079.7010607@garzik.org> (raw)
In-Reply-To: <20100217130847.16338.55586.stgit@localhost.localdomain>
On 02/17/2010 08:10 AM, Alan Cox wrote:
> Avoid the device select overhead on every qc_issue (> 10uS) by caching the
> currently selected device. This shows up on profiles under load. Best case
> this costs us 10uS for the delay, worst case with a dumb interface it's
> costing us about *1mS* a command.
>
> I believe the logic here is sufficient, but would welcome some second reviews
> as its not something you want to get wrong !
>
>
> Signed-off-by: Alan Cox<alan@linux.intel.com>
> ---
>
> drivers/ata/libata-sff.c | 8 ++++++--
> include/linux/libata.h | 1 +
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
>
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 63d9c6a..cf0332a 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -469,6 +469,7 @@ void ata_sff_dev_select(struct ata_port *ap, unsigned int device)
>
> iowrite8(tmp, ap->ioaddr.device_addr);
> ata_sff_pause(ap); /* needed; also flushes, for mmio */
> + ap->sff_selected = device;
> }
> EXPORT_SYMBOL_GPL(ata_sff_dev_select);
>
> @@ -1538,7 +1539,8 @@ unsigned int ata_sff_qc_issue(struct ata_queued_cmd *qc)
> }
>
> /* select the device */
> - ata_dev_select(ap, qc->dev->devno, 1, 0);
> + if (qc->dev->devno != ap->sff_selected)
> + ata_dev_select(ap, qc->dev->devno, 1, 0);
>
> /* start the command */
> switch (qc->tf.protocol) {
My main worry here is that this logic excises the 150ms wait in
ata_dev_select() that has been used effectively to allow ATAPI devices
to "collect themselves" after waiting for idle, prior to command issuance.
Jeff
next prev parent reply other threads:[~2010-03-01 20:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-17 13:10 [RFC 1/4] libata: cache device select Alan Cox
2010-02-17 13:11 ` [RFC 2/4] libata: Remove excess delay in the tf_load path Alan Cox
2010-02-17 13:13 ` [RFC 3/4] libata: Remove excess command issue delays Alan Cox
2010-02-17 14:10 ` Sergei Shtylyov
2010-02-17 15:34 ` Alan Cox
2010-02-17 13:15 ` [RFC 4/4] libata: Make sil680 do its own exec_command posting Alan Cox
2010-02-18 5:13 ` [RFC 1/4] libata: cache device select Mark Lord
2010-02-18 10:16 ` Alan Cox
2010-03-01 20:15 ` Jeff Garzik [this message]
2010-03-02 17:28 ` Alan Cox
2010-03-02 17:28 ` Alan Cox
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=4B8C2079.7010607@garzik.org \
--to=jeff@garzik.org \
--cc=alan@linux.intel.com \
--cc=jeff@garzik.org.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.