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 21:37:35 +0200
From:   Jan Kara <jack@...e.cz>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Jan Kara <jack@...e.cz>, "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 Wed 12-09-18 12:29:50, Andreas Dilger wrote:
> 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()?

Hum, I don't understand. With readahead enabled, we should be submitting
larger batches of IO as generated by ->readpages call and ->readpage
actually never ends up issuing any IO (see how generic_file_buffered_read()
calls page_cache_sync_readahead() first which ends up locking pages and
submitting reads) and only then we go, search for the page again and lock
it - which effectively waits for the readahead to pull in the first page.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR