linux-kernel - Re: [PATCH v2 2/2] block/mq-deadline: Prioritize first request

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]

Date:   Sat, 23 Jul 2022 18:59:09 +0800
From:   Wang You <wangyoua@...ontech.com>
To:     bvanassche@....org
Cc:     axboe@...nel.dk, fio@...r.kernel.org, hch@....de,
        jaegeuk@...nel.org, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, ming.lei@...hat.com,
        wangxiaohua@...ontech.com, wangyoua@...ontech.com
Subject: Re: [PATCH v2 2/2] block/mq-deadline: Prioritize first request

> What is MG04ACA400N?

It is a Toshiba 7200 RPM hard drive.

> The above results are low enough such that these could come from a hard 
> disk. However, the test results are hard to interpret since the I/O 
> pattern is neither perfectly sequential nor perfectly random (32 
> sequential jobs). Please provide separate measurements for sequential 
> and random I/O.

> The above results show that this patch makes reading from a hard disk 
> slower. Isn't the primary use case of mq-deadline to make reading from 
> hard disks faster? So why should these two patches be applied if these 
> slow down reading from a hard disk?

The data of MG04ACA400N on the raid controller is obviously different from 
the single disk, especially the reading data, I did not expect this situation, 
the data on the raid controller made me mistakenly think that the same applies 
to HDD.

I will re-analyze the impact of this patch on the HDD later, please ignore it 
for now.

Also, can I ask? If using fio or other tools, how should testing be done to get 
more accurate and convincing data? Such as the perfectly sequential and random I/O 
performance you mentioned above (fio's multi-threaded test does result in neither 
perfectly sequential nor perfectly random, but single thread dispatch is too slow, 
and cannot play the merge and sorting ability of elv).

Thanks,

Wang.