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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 12 Sep 2018 12:29:50 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Jan Kara <jack@...e.cz>
Cc:     "Theodore Y. Ts'o" <tytso@....edu>,
        "Bean Huo (beanhuo)" <beanhuo@...ron.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "beanhuo.linux@...gle.com" <beanhuo.linux@...gle.com>
Subject: Re: [EXT] how to disable readahead

On Sep 12, 2018, at 9:13 AM, Jan Kara <jack@...e.cz> wrote:
> 
> On Thu 02-08-18 12:58:04, Theodore Y. Ts'o wrote:
>> On Thu, Aug 02, 2018 at 01:56:41PM +0000, Bean Huo (beanhuo) wrote:
>>> 
>>> I am newbie on ext4, I tried the above method to disable readahead,
>>> echo 0 > /sys/block/<dev>/queue/read_ahead_kb Then I read by 128kB
>>> chunk size, ext4 will read the file by 4KB chunk size each
>>> time. that means ext4 splits 128KB into 32 4KB to read.  That's not
>>> my expectation.  Do you know how to still keep and let ext4 read by
>>> 128KB in case of disable readahead?
>> 
>> Hmm... that's not my expectation as well, but I've replicated your
>> results.  More interestingly, I tried the same experiment using XFS,
>> and it does the same thing.  I used as my test workload:
>> 
>> dd if=/mnt/test bs=128k count=32 | sum
>> 
>> Used strace to verify that dd was in fact issuing 128k reads:
>> 
>> read(0, "\377\253a)\307\10\230\6\360,,:\226Rq\204\343\2522&44\307\341\372\271\271/\224#?\346"..., 131072) = 131072
>> write(1, "\377\253a)\307\10\230\6\360,,:\226Rq\204\343\2522&44\307\341\372\271\271/\224#?\346"..., 131072) = 131072
>> 
>> And then used btrace to monitor the I/O requests sent to the device:
>> 
>> 252,4    0      413     0.077274997 14645  Q   R 4408 + 8 [dd]
>> 252,4    2       77     0.077355648  5529  C   R 4408 + 8 [0]
>> 252,4    0      414     0.077393725 14645  Q   R 4416 + 8 [dd]
>> 252,4    2       78     0.077630722  5529  C   R 4416 + 8 [0]
>> 	...
>> 
>> ... and indeed, the reads are being sent to the device in 4k chunks.
>> That's indeed surprising.  I'd have to do some debugging with
>> tracepoints to see what requests are being issued from the
>> mm/filemap.c to the file system.
> 
> And this is in fact expected. There are two basic ways how data can appear
> in page cache: ->readpage and ->readpages filesystem callbacks. The second
> one is what readahead (and only readahead) uses, the first one is used as a
> fallback when readahead fails for some reason. So if you disable readahead,
> you're left only with ->readpage call which does only one-page (4k) reads.

Even *with* readahead, why would we add the overhead of processing each page
separately instead of handling all pages in a single batch via readpages()?

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)