On Tue, Jul 14, 2020 at 12:19:07PM +0200, Hannes Reinecke wrote: > On 7/14/20 11:53 AM, John Garry wrote: > > On 14/07/2020 09:06, Ming Lei wrote: > >>> v7 is here: > >>> > >>> https://github.com/hisilicon/kernel-dev/commits/private-topic-blk-mq-shared-tags-rfc-v7 > >>> > >>> > >>> So that should be good to test with for now. > >>> > >>> And I was going to ask this same question about smartpqi, so can you > >>> please > >>> let me know about this one? > > > > Hi Ming, > > > >> smartpqi is real MQ HBA, do you need any change wrt. shared tags? > > > > Is it really? > > > > As I see, today it maintains a single tagset per HBA. So Hannes' change > > in this series seems ok. However, I do worry that mainline code may be > > wrong, as block layer may send can_queue * nr_hw_queues requests, when > > it seems the HBA can only handle can_queue requests. > > > Correct. There is only one tagset per host, even if the host supports > several queues (guess why it's called smart PQI :-). > And mainline code isn't really wrong, it just allocates the next free > tag from the host tagset; it's not using the block-layer tags at all. > Precisely because the block layer currently cannot guarantee that tags > are unique per host. OK, pqi_alloc_io_request() does the real tag allocation, which looks a very bad implementation, cause the real tags can be used up easily. In my machine, there are 32 queues(32 cpu cores), each queue has 1013 tags, so there can be 32*1013 requests coming from block layer, meantime smartpqi can only handles 1013 requests. I guess it isn't hard to trigger softlock by running heavy/concurrent smartpqi IO. > > And the point of this patchset is exactly that the block layer will only > send up to 'can_queue' requests, irrespective on how many hardware > queues are present. That is only true for shared tags. Thanks, Ming
