Messages in this thread | | | Subject | Re: [PATCH 1/4] block: add scalable completion tracking of requests | From | Jens Axboe <> | Date | Sat, 5 Nov 2016 14:59:47 -0600 |
| |
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
| |