linux-ext4 - RE: [EXT] how to disable readahead

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

Message-ID: <4f846fe7fc9f41e590fe733d6997676b@SIWEX5A.sing.micron.com>
Date:   Wed, 19 Sep 2018 14:52:23 +0000
From:   "Bean Huo (beanhuo)" <beanhuo@...ron.com>
To:     "Bean Huo (beanhuo)" <beanhuo@...ron.com>, Jan Kara <jack@...e.cz>
CC:     Andreas Dilger <adilger@...ger.ca>,
        "jeffm@...e.com" <jeffm@...e.com>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "Zoltan Szubbocsev (zszubbocsev)" <zszubbocsev@...ron.com>
Subject: RE: [EXT] how to disable readahead

>>
>>OK, so you made me look into details how the read request size gets
>>computed :).  The thing is: When read_ahead_kb is 0, we really do
>>single page reads as all the cleverness in trying to issue large read requests
>gets disabled.
>>Once read_ahead_kb is >0 (you have to write there at least PAGE_SIZE -
>>i.e.  4 on x86_64), we will actually issue requests of size at least
>>requested in the syscall.
>>
>>								Honza
>>--
>>Jan Kara <jack@...e.com>
>>SUSE Labs, CR
>
>Meanwhile, I noticed that if 'read_ahead_kb' is 128(128KB), when you read
>the data in 512KB chunk size, The 512KB request data length will be split into
>4*128KB requests to read from HW device; When the 'read_ahead_kb' is 512
>(512kB), the 512kB chunk read request will directly pass to lower layers.
>This also doesn't make sense.  Lower layers can buffer 512KB size data, 512KB
>shouldn't be split into 4 times 128KB.
>
>
>--Bean Huo
>

I did simple performance testing on my platform, there is huge impact on the read performance:

Testing condition: Sync I/O, read/write chunk size is 512KB

read_ahead_kb = 128, random read 443215.64 kB/sec
		            random write 364662.21 kB/sec
		            sequential read 503381.95 kB/sec

read_ahead_kb = 512, random read 534232.84 kB/sec
		            random write 336783.41 kB/sec
		            sequential read 544225.89 kB/sec

--Bean huo