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

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,

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.

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.

Thanks,
John