On Tue, Aug 04, 2020 at 06:00:52PM +0100, John Garry wrote:

On 28/07/2020 09:45, Ming Lei wrote:

quoted

quoted

OK, so dynamically allocating the sbitmap could be good. I was thinking
previously that we still allocate for nr_cpus size, and search a limited
range - but this would have heavier runtime overhead.

So if you really think that this may have some value, then let me know, so
we can look to take it forward.

Hi Ming,

quoted

Forget to mention, the in-tree code has been this shape for long
time, please see sbitmap_resize() called from blk_mq_map_swqueue().

So after the resize, even if we are only checking a single word and a few
bits within that word, we still need 2x 64b loads - 1x for .word and 1x for
.cleared. Seems a bit inefficient for caching when we have a 1:1 mapping or
similar. For 1:1 case only, how about a ctx_map per queue for all hctx, with
a single bit per hctx? I do realize that it makes the code more complicated,
but it could be more efficient.

IMO, the cost for accessing one bit and one word is basically same.

Another thing to consider is that for ctx_map, we don't do deferred bit
clear, so we don't ever really need to check .cleared there. I think.

That looks true.

However, in case of MQ, the normal code path is direct issue, not sure if
we need this kind of optimization.

BTW, no matter if hostwide tags is used or not, the problem is in always
run-queue from scsi_end_request(). As we discussed, the re-run queue is
only needed in case of budget contention.


Thanks,
Ming