[LTP] [PATCH v2] syscalls/readahead02: limit max readahead to backing device max_readahead_kb

[Amir Goldstein]

On Tue, Mar 5, 2019 at 10:22 PM Jan Stancek <jstancek@redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > On Tue, Mar 5, 2019 at 6:55 PM Jan Stancek <jstancek@redhat.com> wrote:
> > >
> > >
> > > ----- Original Message -----
> > > > On Tue, Mar 5, 2019 at 6:17 PM Jan Stancek <jstancek@redhat.com> wrote:
> > > > >
> > > > > Using system-wide "Cached" size is not accurate. The test is
> > > > > sporadically
> > > > > failing with warning on ppc64le 4.18 and 5.0 kernels.
> > > > >
> > > > > Problem is that test over-estimates max readahead size, which then
> > > > > leads to fewer readhead calls and kernel can silently trims length
> > > > > in each of them:
> > > > >   ...
> > > > >   readahead02.c:244: INFO: Test #2: POSIX_FADV_WILLNEED on file
> > > > >   readahead02.c:134: INFO: creating test file of size: 67108864
> > > > >   readahead02.c:263: INFO: read_testfile(0)
> > > > >   readahead02.c:274: INFO: read_testfile(1)
> > > > >   readahead02.c:189: INFO: max ra estimate: 12320768
> > > > >   readahead02.c:198: INFO: readahead calls made: 6
> > > > >   readahead02.c:204: PASS: offset is still at 0 as expected
> > > > >   readahead02.c:308: INFO: read_testfile(0) took: 492486 usec
> > > > >   readahead02.c:309: INFO: read_testfile(1) took: 430627 usec
> > > > >   readahead02.c:311: INFO: read_testfile(0) read: 67108864 bytes
> > > > >   readahead02.c:313: INFO: read_testfile(1) read: 59244544 bytes
> > > > >   readahead02.c:316: PASS: readahead saved some I/O
> > > > >   readahead02.c:324: INFO: cache can hold at least: 264192 kB
> > > > >   readahead02.c:325: INFO: read_testfile(0) used cache: 124992 kB
> > > > >   readahead02.c:326: INFO: read_testfile(1) used cache: 12032 kB
> > > > >   readahead02.c:338: WARN: using less cache than expected
> > > > >
> > > > > Stop relying on used cache size, and use backing device readahead
> > > > > limit instead.
> > > > >
> > > >
> > > > This is certainly better than 4K, but still feels like we are not really
> > > > testing
> > > > the API properly, but I'm fine with this fix.
> > > >
> > > > However... as follow up, how about extending the new
> > > > tst_dev_bytes_written() utils from Sumit to cover also bytes_read
> > > > and replace validation of readahead() from get_cached_size() diff
> > > > to tst_dev_bytes_read()?
> > >
> > > There is something similar based on /proc/self/io. We could try using
> > > that to estimate max readahead size.
> > >
> > > Or /sys/class/block/$dev/stat as you suggested, not sure which one is
> > > more accurate/up to date.
> > >
> >
> > I believe /proc/self/io doesn't count IO performed by kernel async
> > readahead against the process that issued the readahead, but didn't
> > check. The test uses /proc/self/io to check how many IO where avoided
> > by readahead...
>
> We could do one readahead() on entire file, then read
> the file and see how many IO we didn't manage to avoid.
> The difference between filesize and IO we couldn't avoid,
> would be our max readahead size.
>

Sounds good.

Thanks,
Amir.