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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Jan 2020 05:00:53 +0530 From: Ritesh Harjani <riteshh@...ux.ibm.com> To: "Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz> Cc: Xiaoguang Wang <xiaoguang.wang@...ux.alibaba.com>, Ext4 Developers List <linux-ext4@...r.kernel.org>, joseph.qi@...ux.alibaba.com, Liu Bo <bo.liu@...ux.alibaba.com> Subject: Re: Discussion: is it time to remove dioread_nolock? On 1/9/20 10:08 PM, Theodore Y. Ts'o wrote: > On Thu, Jan 09, 2020 at 02:51:42PM +0530, Ritesh Harjani wrote: >>> Dbench was slightly impacted; I didn't see any real differences with >>> compilebench or postmark. dioread_nolock did improve fio with >>> sequential reads; which is interesting, since I would have expected >> >> IIUC, this Seq. read numbers are with --direct=1 & bs=2MB & ioengine=libaio, >> correct? >> So essentially it will do a DIO AIO sequential read. > > Correct. I too collected some performance numbers on my x86 box with --direct=1, bs=4K/1M & ioengine=libaio, with default opt v/s dioread_nolock opt on latest ext4 git tree. I found the delta to be within +/- 6% in all of the runs which includes, seq read, mixed rw & mixed randrw. -ritesh
Powered by blists - more mailing lists