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
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
