All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH/RFC] syscalls/readahead02: don't use cache size
Date: Tue, 5 Mar 2019 10:17:22 -0500 (EST)	[thread overview]
Message-ID: <565188461.5295049.1551799042924.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhqzTBkxva3Zhreb6o=EjnyFUkLutEjuNd8+jPn9bVr6w@mail.gmail.com>


----- Original Message -----
> On Tue, Mar 5, 2019 at 2:34 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 minimal sane readahead length,
> > that should work across all systems.
> 
> But now instead of over estimating readahead length you definetly
> underestimate it resulting in way too many readahead calls
> (reahead every 4K block), which does not validate long readahead
> code is working at all.

We could try to cap on backing device read_ahead_kb.

> 
> How about this patch instead.
> Can you say with sufficient confidence if it solves the sporadic errors?

It likely won't. We started at 2M couple years back, but there
were several commit that keep changing the limit: [1][2]

[1] 600e19afc5f8a6c18ea49cee9511c5797db02391
[2] https://lkml.org/lkml/2016/7/25/308

> Also, IMO if you solve the estimation problem, there is no need to
> remove the WARNING, it may still be informative.
> 
> Thanks,
> Amir.
> 
> --- a/testcases/kernel/syscalls/readahead/readahead02.c
> +++ b/testcases/kernel/syscalls/readahead/readahead02.c
> @@ -50,6 +50,8 @@ static int ovl_mounted;
>  #define OVL_WORK       MNTPOINT"/work"
>  #define OVL_MNT                MNTPOINT"/ovl"
>  #define MIN_SANE_READAHEAD (4u * 1024u)
> +/* To avoid over estimation of readahead length */
> +#define MAX_SANE_READAHEAD (1024u * 1024u)
> 
>  static const char mntpoint[] = MNTPOINT;
> 
> @@ -193,7 +195,7 @@ static int read_testfile(struct tcase *tc, int
> do_readahead,
>                         }
> 
>                         i++;
> -                       offset += max_ra_estimate;
> +                       offset += MIN(max_ra_estimate, MAX_SANE_READAHEAD);
>                 } while ((size_t)offset < fsize);
>                 tst_res(TINFO, "readahead calls made: %zu", i);
>                 *cached = get_cached_size();
> 

  reply	other threads:[~2019-03-05 15:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 12:34 [LTP] [PATCH/RFC] syscalls/readahead02: don't use cache size Jan Stancek
2019-03-05 13:53 ` Amir Goldstein
2019-03-05 15:17   ` Jan Stancek [this message]
2019-03-05 15:33     ` Amir Goldstein
2019-03-05 16:17       ` [LTP] [PATCH v2] syscalls/readahead02: limit max readahead to backing device max_readahead_kb Jan Stancek
2019-03-05 16:35         ` Amir Goldstein
2019-03-05 16:55           ` Jan Stancek
2019-03-05 20:08             ` Amir Goldstein
2019-03-05 20:22               ` Jan Stancek
2019-03-05 20:44                 ` Amir Goldstein
2019-03-06 16:42                   ` Jan Stancek
2019-03-07  6:41                     ` Amir Goldstein
2019-03-07  8:18                       ` Jan Stancek
2019-03-07  8:48                         ` Amir Goldstein
2019-03-07  9:15                           ` Jan Stancek
2019-03-07  9:53                             ` Amir Goldstein
2019-03-07 11:25                               ` Jan Stancek
2019-03-07 11:49                                 ` Amir Goldstein
2019-03-08 12:19                                   ` [LTP] [PATCH v4] syscalls/readahead02: set readahead to min(bdi limit, 2M) Jan Stancek
2019-03-08 14:29                                     ` Amir Goldstein
2019-03-08 14:56                                       ` Jan Stancek
2019-03-12 13:46                                     ` Li Wang
2019-03-12 15:26                                       ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=565188461.5295049.1551799042924.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.