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

Hannes Reinecke
2019-11-27T17:02:59Z

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)