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\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@xxxxxxxx> SUSE Labs, CR
