All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shli@fb.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: IDE/ATA development list <linux-ide@vger.kernel.org>,
	Jens Axboe <axboe@fb.com>, Tejun Heo <tj@kernel.org>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 2/2] libata: micro-optimize tag allocation
Date: Fri, 16 Jan 2015 15:55:45 -0800	[thread overview]
Message-ID: <20150116235545.GA1358222@devbig257.prn2.facebook.com> (raw)
In-Reply-To: <CAPcyv4hWkWFYH1+d9nmw=bP-2X2kR=V4w=nEZ=QyOSMdpYAk3g@mail.gmail.com>

On Fri, Jan 16, 2015 at 03:49:07PM -0800, Dan Williams wrote:
> On Fri, Jan 16, 2015 at 3:31 PM, Shaohua Li <shli@fb.com> wrote:
> > On Fri, Jan 16, 2015 at 03:13:08PM -0800, Dan Williams wrote:
> >> Jens notes, "libata tag allocator sucks. Like seriously sucks, it's
> >> almost a worst case implementation."  Previously I thought SATA mmio
> >> latency dominated performance profiles, but as Tejun notes:
> >>
> >>   "Hmmm... one problem with the existing tag allocator in ata is that
> >>    it's not very efficient which actually shows up in profile when libata
> >>    is used with a very zippy SSD.  Given that ata needs a different
> >>    allocation policies anyway maybe the right thing to do is making the
> >>    existing allocator suck less."
> >>
> >> So replace it with a naive enhancement that also supports the existing
> >> quirks.  Hopefully, soon to be replaced by Shaohua's patches [1], but
> >> those do not yet support the quirk needed by sil24 (ATA_FLAG_LOWTAG)
> >> [2].
> >>
> >> [1]: https://urldefense.proofpoint.com/v1/url?u=http://marc.info/?l%3Dlinux-ide%26m%3D142137195324687%26w%3D2&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=3RFlL12A7nwmLRXunVJq2g%3D%3D%0A&m=5iyIBsm0XLUeBFFdEfPvaP6LL8KiN2TcuEGgJH6RzTc%3D%0A&s=cea914a77883ea668400a1f19621d1241cab16f6a4c0e68d0749de4c2448cdb1
> >> [2]: https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.kernel.org/show_bug.cgi?id%3D87101&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=3RFlL12A7nwmLRXunVJq2g%3D%3D%0A&m=5iyIBsm0XLUeBFFdEfPvaP6LL8KiN2TcuEGgJH6RzTc%3D%0A&s=82d11bc720e9f0cbd0ad6aa7e8ece18315ac1e4f97cb02d49460893e5006228e
> >
> > with my patch, we can fix this as:
> >
> >
> > diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c
> > index d81b20d..5242897 100644
> > --- a/drivers/ata/sata_sil24.c
> > +++ b/drivers/ata/sata_sil24.c
> > @@ -388,6 +388,7 @@ static struct scsi_host_template sil24_sht = {
> >         .can_queue              = SIL24_MAX_CMDS,
> >         .sg_tablesize           = SIL24_MAX_SGE,
> >         .dma_boundary           = ATA_DMA_BOUNDARY,
> > +       .tag_alloc_policy       = BLK_TAG_ALLOC_FIFO,
> >  };
> >
> >  static struct ata_port_operations sil24_ops = {
> 
> Ok, thanks for that.
> 
> We still need patch1 as the minimal fix for the regression, agreed?

The BLK_TAG_ALLOC_FIFO will make blk/blk-mq tag allocation allocates
lowest tag (eg, FIFO). So I thought it already fixes the sil24 bug, if I
understand the bug clearly.

Thanks,
Shaohua

  reply	other threads:[~2015-01-16 23:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 23:12 [PATCH 0/2] fix sil24 regression and muddy the ata tag allocation waters Dan Williams
2015-01-16 23:13 ` [PATCH 1/2] libata: allow sata_sil24 to opt-out of tag ordered submission Dan Williams
2015-01-17 10:59   ` Sergei Shtylyov
     [not found]     ` <CAPcyv4h3n+cnvADiEbGgi1EFCqEwhzZ7gt_6XUmSC62aOf2Dzw@mail.gmail.com>
2015-01-17 18:43       ` Sergei Shtylyov
2015-01-19 14:12     ` Tejun Heo
2015-01-19 14:24       ` Sergei Shtylyov
2015-01-19 14:27         ` Tejun Heo
2015-01-19 14:13   ` Tejun Heo
2015-01-16 23:13 ` [PATCH 2/2] libata: micro-optimize tag allocation Dan Williams
2015-01-16 23:17   ` Jens Axboe
2015-01-16 23:19     ` Dan Williams
2015-01-16 23:21     ` Jens Axboe
2015-01-16 23:38       ` Dan Williams
2015-01-16 23:31   ` Shaohua Li
2015-01-16 23:49     ` Dan Williams
2015-01-16 23:55       ` Shaohua Li [this message]
2015-01-16 23:59         ` Dan Williams
2015-01-17  0:10           ` Shaohua Li
2015-01-19 14:14   ` Tejun Heo

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=20150116235545.GA1358222@devbig257.prn2.facebook.com \
    --to=shli@fb.com \
    --cc=axboe@fb.com \
    --cc=dan.j.williams@intel.com \
    --cc=hch@infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=tj@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.