Re: [PATCH 4/8] blk-mq: Facilitate a shared sbitmap per tagset

[Hannes Reinecke <hare@suse.de>]

On 11/26/19 4:54 PM, Ming Lei wrote:
> On Tue, Nov 26, 2019 at 12:27:50PM +0100, Hannes Reinecke wrote:
>> On 11/26/19 12:05 PM, Ming Lei wrote:
[ .. ]
>>>  From performance viewpoint, all hctx belonging to this request queue should
>>> share one scheduler tagset in case of BLK_MQ_F_TAG_HCTX_SHARED, cause
>>> driver tag queue depth isn't changed.
>>>
>> Hmm. Now you get me confused.
>> In an earlier mail you said:
>>
>>> This kind of sharing is wrong, sched tags should be request
>>> queue wide instead of tagset wide, and each request queue has
>>> its own & independent scheduler queue.
>>
>> as in v2 we _had_ shared scheduler tags, too.
>> Did I misread your comment above?
> 
> Yes, what I meant is that we can't share sched tags in tagset wide.
> 
> Now I mean we should share sched tags among all hctxs in same request
> queue, and I believe I have described it clearly.
> 
I wonder if this makes a big difference; in the end, scheduler tags are 
primarily there to allow the scheduler to queue more requests, and 
potentially merge them. These tags are later converted into 'real' ones 
via blk_mq_get_driver_tag(), and only then the resource limitation takes 
hold.
Wouldn't it be sufficient to look at the number of outstanding commands 
per queue when getting a scheduler tag, and not having to implement yet 
another bitmap?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                              +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)