From: Richard Palethorpe <rpalethorpe@suse.de>
To: Li Wang <liwang@redhat.com>
Cc: Paul Bunyan <pbunyan@redhat.com>,
Rafael Aquini <aquini@redhat.com>,
ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] madvise06: shrink to 3 MADV_WILLNEED pages to stabilize the test
Date: Tue, 21 Jun 2022 09:27:56 +0100 [thread overview]
Message-ID: <875yku5sjy.fsf@suse.de> (raw)
In-Reply-To: <20220621034729.551200-1-liwang@redhat.com>
Hello Li,
Li Wang <liwang@redhat.com> writes:
> Paul Bunyan reports that the madvise06 test fails intermittently with many
> LTS kernels, after checking with mm developer we prefer to think this is
> more like a test issue (but not kernel bug):
>
> madvise06.c:231: TFAIL: 4 pages were faulted out of 2 max
>
> So this improvement is target to reduce the false positive happens from
> three points:
>
> 1. Adding the while-loop to give more chances for madvise_willneed()
> reads memory asynchronously
> 2. Raise value of `loop` to let test waiting for more times if swapchache
> haven't reached the expected
> 3. Shrink to only 3 pages for verifying MADV_WILLNEED that to make the
> system easily takes effect on it
>
> From Rafael Aquini:
>
> The problem here is that MADV_WILLNEED is an asynchronous non-blocking
> hint, which will tell the kernel to start doing read-ahead work for the
> hinted memory chunk, but will not wait up for the read-ahead to finish.
> So, it is possible that when the dirty_pages() call start re-dirtying
> the pages in that target area, is racing against a scheduled swap-in
> read-ahead that hasn't yet finished. Expecting faulting only 2 pages
> out of 102400 also seems too strict for a PASS threshold.
>
> Note:
> As Rafael suggested, another possible approach to tackle this failure
> is to tally up, and loosen the threshold to more than 2 major faults
> after a call to madvise() with MADV_WILLNEED.
> But from my test, seems the faulted-out page shows a significant
> variance in different platforms, so I didn't take this way.
>
> Btw, this patch get passed on my two easy reproducible systems more than 1000 times
>
> Reported-by: Paul Bunyan <pbunyan@redhat.com>
> Signed-off-by: Li Wang <liwang@redhat.com>
> Cc: Rafael Aquini <aquini@redhat.com>
> Cc: Richard Palethorpe <rpalethorpe@suse.com>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-06-21 8:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 3:47 [LTP] [PATCH v2] madvise06: shrink to 3 MADV_WILLNEED pages to stabilize the test Li Wang
2022-06-21 8:27 ` Richard Palethorpe [this message]
2022-06-22 1:24 ` Li Wang
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=875yku5sjy.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=aquini@redhat.com \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=pbunyan@redhat.com \
/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