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