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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx/

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@xxxxxxxxxxxxxx/

Thanks,
John





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux