Re: [PATCH 1/4] block: add scalable completion tracking of requests

[Jens Axboe]

On 11/04/2016 05:13 PM, Ming Lei wrote:
> > Yes, that might be a good idea, since it doesn't cost us anything.
> > For the mq case, I'm hard pressed to think of areas where we could
> > complete IO in parallel on the same software queue. You'll never have
> > a software queue mapped to multiple hardware queues. So we should
> > essentially be serialized.
>
> For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
> which is often run from interrupt handler, and the CPU serving the
> interrupt can be different with the submitting CPU for rq->mq_ctx. And
> there can be several CPUs handling the interrupts originating from
> same sw queue.

BTW, one small improvement might be to call blk_mq_stat_add() on the
curent ctx, in case it's different than rq->mq_ctx. That can happen if
we have multiple CPUs per hardware queue. In reality, even for that
case, a real race is rare. You'd have to rebalance interrupt masks
basically, at least on x86 where multiple CPUs in the IRQ affinity mask
still always trigger on the first one.

So while we could just grab the current ctx instead, I don't think it's
going to make a difference in practice.


--
Jens Axboe