On 11/15/19 6:30 AM, Bart Van Assche wrote: > On 11/14/19 1:41 AM, John Garry wrote: >> On 13/11/2019 18:38, Hannes Reinecke wrote: >>>> Hi Hannes, >>>> >>>>> Oh, my. Indeed, that's correct. >>>> >>>> The tags could be kept in sync like this: >>>> >>>> shared_tag = blk_mq_get_tag(shared_tagset); >>>> if (shared_tag != -1) >>>> sbitmap_set(hctx->tags, shared_tag); >>>> >>>> But that's obviously not ideal. >>>> >>> Actually, I _do_ prefer keeping both in sync. >>> We might want to check if the 'normal' tag is set (typically it would not, but then, who knows ...) >>> The beauty here is that both 'shared' and 'normal' tag are in sync, so if a driver would be wanting to use the tag as index into a command array it can do so without any surprises. >>> >>> Why do you think it's not ideal? >> >> A few points: >> - Getting a bit from one tagset and then setting it in another tagset is a bit clunky. >> - There may be an atomicity of the getting the shared tag bit and setting the hctx tag bit - I don't think that there is. >> - Consider that sometimes we may want to check if there is space on a hw queue - checking the hctx tags is not really proper any longer, as typically there would always be space on hctx, but not always the shared tags. We did delete blk_mq_can_queue() yesterday, which >> would be an example of that. Need to check if there are others. >> >> Having said all that, the obvious advantage is performance gain, can still use request.tag and so maybe less intrusive changes. >> >> I'll have a look at the implementation. The devil is mostly in the detail... > > Wouldn't that approach trigger a deadlock if it is attempted to allocate the last > tag from two different hardware queues? How about sharing tag sets across hardware > queues, e.g. like in the (totally untested) patch below? > Why should it? The shared tag map determines which tag should be allocated in the per-hctx map, and as the former is a strict superset of all hctx maps the bit _has_ to be free in the hctx map. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 247165 (AG München), GF: Felix Imendörffer
