public inbox for ltp@lists.linux.it
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox