>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@xxxxxxx> 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\2 >> >> 71\271/\224#?\346"..., 131072) = 131072 write(1, >> >> >"\377\253a)\307\10\230\6\360,,:\226Rq\204\343\2522&44\307\341\372\2 >> >> 71\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@xxxxxxxx> >SUSE Labs, CR 'read_ahead_kb' should be only used for the read ahead (second time read internal), should be used as a flag to change the first read request chunk size came from user space read. Even the 'read_ahead_kb' configured 0. -Beanhuo
