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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 5 Nov 2016 14:59:47 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Ming Lei <tom.leiming@...il.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 1/4] block: add scalable completion tracking of requests

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