On Mon, 12 Jan 2015, Jens Axboe wrote:
On 01/12/2015 10:53 AM, Keith Busch wrote:
Is the nr_active count correct prior to starting the mkfs test? Trying
to see if someone is calling "blk_mq_alloc_tag_set()" twice on the same
set. It might be good to add a WARN if this is detected anyway.
That might be a good debug aid, I agree. But the above doesn't look like it's
corrupted. If you add the values, you get 60 and 62 for the two cases, which
seems to indicate that we did bump the values correctly, but for some reason
we never did the decrement on completion. Hence we stabilize around the queue
depth of the device, which will be 62 +/- a bit due to the sharing.
I'm not familiar with how rq based dm works. We clone the original request
(which has the RQ_MQ_INFLIGHT flag set), then we issue the clone(s) to the
underlying device(s)? And when that completes, we complete the original? That
would work fine with the flag on the original request. Maybe I'm missing
something, and I'll let more knowledgeable people discuss that.
Oh, let's look at "__blk_rq_prep_clone". dm calls that after
blk_get_request() for the blk-mq based multipath types and overrides the
destinations cmd_flags with the source's even though the source was not
allocated from a blk-mq based queue, much less a shared tag.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
