linux-kernel - Re: [PATCH -next RFC v3 0/8] improve tag allocation under heavy load

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <85bfe26e-fb54-6885-8bd5-a450fa07bcd4@huawei.com>
Date:   Mon, 25 Apr 2022 11:27:54 +0800
From:   "yukuai (C)" <yukuai3@...wei.com>
To:     Bart Van Assche <bvanassche@....org>, <axboe@...nel.dk>,
        <andriy.shevchenko@...ux.intel.com>, <john.garry@...wei.com>,
        <ming.lei@...hat.com>, <qiulaibin@...wei.com>
CC:     <linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <yi.zhang@...wei.com>
Subject: Re: [PATCH -next RFC v3 0/8] improve tag allocation under heavy load

在 2022/04/25 11:09, Bart Van Assche 写道:
> On 4/15/22 03:10, Yu Kuai wrote:
>> The single io performance(randwrite):
>>
>> | bs       | 128k | 256k | 512k | 1m   | 1280k | 2m   | 4m   |
>> | -------- | ---- | ---- | ---- | ---- | ----- | ---- | ---- |
>> | bw MiB/s | 20.1 | 33.4 | 51.8 | 67.1 | 74.7  | 82.9 | 82.9 |
> 
> Although the above data is interesting, it is not sufficient. The above 
> data comes from a setup with a single hard disk. There are many other 
> configurations that are relevant (hard disk array, high speed NVMe, QD=1 
> USB stick, ...) but for which no conclusions can be drawn from the above 
> data.
Hi,

The original idea is to improve large bs randwrite performance in HDD,
here I just test the specific case in a HDD. It's right many other test
cases and configurations are relevant.
> 
> Another question is whether the approach of this patch series is the 
> right approach? I would expect that round-robin wakeup of waiters would 
> be ideal from a fairness point of view. However, there are patches in 
> this patch series that guarantee that wakeup of tag waiters won't happen 
> in a round robin fashion.

I was thinking that round-robin can't grantee fairness in the corner
case that 8 waitqueues are not balanced. For example, one waitqueue
somehow have lots of waiters, and it's better to handle them before
newcome waiters in other waitqueues.

How you think abount this way, keep round-robin wakeup if waitqueues
are balanced, otherwise choose the waitqueue with the max waiters.

Thanks,
Kuai
> 
> Thanks,
> 
> Bart.
> .
>