All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4] syscalls/readahead02: set readahead to min(bdi limit, 2M)
Date: Tue, 12 Mar 2019 11:26:20 -0400 (EDT)	[thread overview]
Message-ID: <675507642.7201880.1552404380160.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAEemH2eQ2wpVWDeH2jPoD7rMec7yU2RCnpTw4WkqozkhWovoNw@mail.gmail.com>



----- Original Message -----
> On Fri, Mar 8, 2019 at 8:19 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
> >
> > Try raising bdi readahead limit as much as we can. We write and read back
> > "read_ahead_kb" sysfs value, starting with filesize. If that fails, we try
> > again with lower value.
> >
> > readahead_length used in the test is then set to MIN(bdi limit, 2M),
> > so we respect also kernels prior to commit 600e19afc5f8 ("mm: use
> > only per-device readahead limit").
> >
> > Signed-off-by: Jan Stancek <jstancek@redhat.com>
> >
> 
> Tested-by: Li Wang <liwang@redhat.com>
> 
> I run this patch for more than 100 times on my ppc64le 4.18 platform, and
> confirmed the problem is no longer appear.

Thanks, my testing also looks good.

Pushed.

Regards,
Jan

      reply	other threads:[~2019-03-12 15:26 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
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 [this message]

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=675507642.7201880.1552404380160.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.