Re: [PATCH] blk-mq: test QUEUE_FLAG_HCTX_ACTIVE for sbitmap_shared in hctx_may_queue

[Ming Lei <ming.lei@redhat.com>]

On Tue, Jan 05, 2021 at 11:38:48AM +0000, John Garry wrote:
> On 05/01/2021 11:18, Ming Lei wrote:
> > > > > ot set normally..
> > > > It always return true, and might just take a bit more CPU especially the tag queue
> > > > depth of magsas_raid and hisi_sas_v3 is quite high.
> > > Hi Ming,
> > > 
> > > Right, but we actually tested by hacking the host tag queue depth to be
> > > lower such that we should have tag contention, here is an extract from the
> > > original series cover letter for my results:
> > > 
> > > Tag depth 		4000 (default)		260**
> > > 
> > > Baseline (v5.9-rc1):
> > > none sched:		2094K IOPS		513K
> > > mq-deadline sched:	2145K IOPS		1336K
> > > 
> > > Final, host_tagset=0 in LLDD *, ***:
> > > none sched:		2120K IOPS		550K
> > > mq-deadline sched:	2121K IOPS		1309K
> > > 
> > > Final ***:
> > > none sched:		2132K IOPS		1185		
> > > mq-deadline sched:	2145K IOPS		2097	
> > > 
> > > Maybe my test did not expose the issue. Kashyap also tested this and
> > > reported the original issue such that we needed this feature, so I'm
> > > confused.
> 
> Hi Ming,
> 
> > How many LUNs are involved in above test with 260 depth?
> 
> For me, there was 12 SAS SSDs; for convenience here is the cover letter with
> details:
> https://lore.kernel.org/linux-block/1597850436-116171-1-git-send-email-john.garry@huawei.com/
> 
> IIRC, for megaraid sas, Kashyap used many more LUNs for testing (64) and
> high fio depth (128) but did not reduce .can_queue, topic originally raised
> here:
> https://lore.kernel.org/linux-block/29f8062c1fccace73c45252073232917@mail.gmail.com/

OK, in both tests, nr_luns are big enough wrt. 260 depth. Maybe that is
why very low IOPS is observed in 'Final(hosttag=1)' with 260 depth.

I'd suggest to run your previous test again after applying this patch,
and see if difference can be observed.

-- 
Ming