linux-kernel - Re: [RFC] blk-mq: clean up the hctx restart

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 2 Aug 2018 17:08:55 +0000
From:   Bart Van Assche <Bart.VanAssche@....com>
To:     "ming.lei@...hat.com" <ming.lei@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "jianchao.w.wang@...cle.com" <jianchao.w.wang@...cle.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>
Subject: Re: [RFC] blk-mq: clean up the hctx restart

On Fri, 2018-08-03 at 00:58 +0800, Ming Lei wrote:
> And about the situations you mentioned, no any special as normal cases
> or thousands of LUNs. Just a batch of queues are waken up from one
> single wait queue(sbq_wait_state), and inside each wait queue, queues
> are handled actually in FIFO order.
> 
> Or what is your expected ideal behaviour about fairness?

Hello Ming,

What I expect is if the number of LUNs is really large that all LUNs are treated
equally. Unless someone can set up a test that demonstrates that this is still
the case for commit 97889f9ac24f ("blk-mq: remove synchronize_rcu() from
blk_mq_del_queue_tag_set()"), I will assume that that commit breaks fairness.

Bart.