From: Ming Lei <ming.lei@redhat.com>
To: John Garry <john.garry@huawei.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
jejb@linux.vnet.ibm.com, linuxarm@huawei.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
chenxiang <chenxiang66@hisilicon.com>,
Kashyap Desai <kashyap.desai@broadcom.com>
Subject: Re: [PATCH 0/7] hisi_sas: Misc bugfixes and an optimisation patch
Date: Fri, 12 Oct 2018 21:30:20 +0800 [thread overview]
Message-ID: <20181012133019.GA5361@ming.t460p> (raw)
In-Reply-To: <3322d066-d118-320f-eb99-0fb03d530c67@huawei.com>
On Fri, Oct 12, 2018 at 10:02:57AM +0100, John Garry wrote:
> Hi Ming,
>
> > In theory, you still may generate and manage the IPTT in the LLDD by
> > simply ignoring rq->tag, meantime enabling SCSI_MQ with 16 hw queues.
> >
>
> Well at the moment we can't expose all 16 hw queues to upper layer anyway,
> due to ordering restiction imposed by HW on LLDD. We have a plan to solve
> it.
>
> Regardless, we still found performance better by using rq tag instead of
> exposing all 16 queues.
>
> > However, not sure how much this way may improve performance, and it may
> > degrade IO perf. If 16 hw queues are exposed to blk-mq, 16*.can_queue
> > requests may be queued to the driver, and allocation & free on the single
> > IPTT pool will become a bottleneck.
>
> Right, this IPTT management doesn't scale (especially for our host with 2
> sockets @ 48/64 cores each). So if upper layer is already generating a tag
> which we can use, good to use it.
>
> >
> > Per my experiment on host tagset, it might be a good tradeoff to allocate
> > one hw queue for each node to avoid the remote access on dispatch
> > data/requests structure for this case, but your IPTT pool is still
> > shared all CPUs, maybe you can try the smart sbitmap.
> >
> > https://www.spinics.net/lists/linux-scsi/msg117920.html
>
> I don't understand this about allocating a hw queue per node. Surely having
> and using all available queues in an intelligent way means less queue
> contention, right?
Yes.
>
> Looking at this change:
> @@ -5761,6 +5762,11 @@ static int hpsa_scsi_host_alloc(struct ctlr_info *h)
> static int hpsa_scsi_add_host(struct ctlr_info *h)
> {
> int rv;
> + /* 256 tags should be high enough to saturate device */
> + int max_queues = DIV_ROUND_UP(h->scsi_host->can_queue, 256);
> +
> + /* per NUMA node hw queue */
> + h->scsi_host->nr_hw_queues = min_t(int, nr_node_ids, max_queues);
>
> I assume h->scsi_host->nr_hw_queues was zero-init previously, so we're now
> using > 1 queue, but why limit?
>From my test on null_blk/scsi_debug, per-node hw queue improves iops
much more obviously.
Also you may manage IPTT in LLD, and contention on the single IPTT pool
shouldn't be very serious, given there are less NUMA nodes usually.
Thanks,
Ming
next prev parent reply other threads:[~2018-10-12 13:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-24 15:06 [PATCH 0/7] hisi_sas: Misc bugfixes and an optimisation patch John Garry
2018-09-24 15:06 ` [PATCH 1/7] scsi: hisi_sas: Feed back linkrate(max/min) when re-attached John Garry
2018-09-24 15:06 ` [PATCH 2/7] scsi: hisi_sas: Move evaluation of hisi_hba in hisi_sas_task_prep() John Garry
2018-09-24 15:06 ` [PATCH 3/7] scsi: hisi_sas: Fix the race between IO completion and timeout for SMP/internal IO John Garry
2018-09-24 15:06 ` [PATCH 4/7] scsi: hisi_sas: Free slot later in slot_complete_vx_hw() John Garry
2018-09-24 15:06 ` [PATCH 5/7] scsi: hisi_sas: unmask interrupts ent72 and ent74 John Garry
2018-09-24 15:06 ` [PATCH 6/7] scsi: hisi_sas: Use block layer tag instead for IPTT John Garry
2018-09-24 15:06 ` [PATCH 7/7] scsi: hisi_sas: Update v3 hw AIP_LIMIT and CFG_AGING_TIME register values John Garry
2018-10-04 15:30 ` [PATCH 0/7] hisi_sas: Misc bugfixes and an optimisation patch John Garry
2018-10-11 1:58 ` Martin K. Petersen
2018-10-11 6:36 ` Christoph Hellwig
2018-10-11 9:59 ` John Garry
2018-10-11 10:15 ` Christoph Hellwig
2018-10-11 13:12 ` John Garry
2018-10-11 13:32 ` Ming Lei
2018-10-11 14:07 ` John Garry
2018-10-11 23:36 ` Ming Lei
2018-10-12 9:02 ` John Garry
2018-10-12 13:30 ` Ming Lei [this message]
2018-10-12 10:47 ` John Garry
2018-10-16 4:28 ` Martin K. Petersen
2018-10-16 8:28 ` John Garry
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=20181012133019.GA5361@ming.t460p \
--to=ming.lei@redhat.com \
--cc=chenxiang66@hisilicon.com \
--cc=hch@infradead.org \
--cc=jejb@linux.vnet.ibm.com \
--cc=john.garry@huawei.com \
--cc=kashyap.desai@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
/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