Matthew Wilcox wrote:
quoted text
> In an I/O heavy workload (IOZone), ahci_qc_issue is the second-highest
> consumer of CPU cycles.  Removing the flush gets us approximately 10%
> bandwidth improvement.  I believe this to be because the CPU can start
> queueing the next request instead of waiting for the readl() to flush the
> writes to the device.  The flush isn't necessary because we're using a
> 'queue' metaphor; we don't guarantee the command has got to the device,
> nor do we need to guarantee the command has got to the controller.
> 
> Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> ---
>  drivers/ata/ahci.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 6a7a70a..58915bd 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1846,7 +1846,6 @@ static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
>  	if (qc->tf.protocol == ATA_PROT_NCQ)
>  		writel(1 << qc->tag, port_mmio + PORT_SCR_ACT);
>  	writel(1 << qc->tag, port_mmio + PORT_CMD_ISSUE);
> -	readl(port_mmio + PORT_CMD_ISSUE);	/* flush */
>  

(LKML CC added for wider review)

As I noted in IRC, I've queued this and am planning to apply this, as 
I've been thinking along the same lines for quite a while now...  not 
just in this driver but other drivers too.

A couple places in libata arguably need additional flushing, but some 
places could actually stand to use /less/

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/