From: Richard Palethorpe <rpalethorpe@suse.de>
To: Li Wang <liwang@redhat.com>
Cc: Yang Xu <xuyang2018.jy@cn.fujitsu.com>,
Yongqiang Liu <liuyongqiang13@huawei.com>,
Paul Bunyan <pbunyan@redhat.com>,
Eirik Fuller <efuller@redhat.com>,
ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] madvise06: Raise the bar for judging failure
Date: Mon, 27 Feb 2023 11:33:18 +0000 [thread overview]
Message-ID: <87fsarb8eb.fsf@suse.de> (raw)
In-Reply-To: <20230218040919.3548296-1-liwang@redhat.com>
Hell Li,
Li Wang <liwang@redhat.com> writes:
> There is an intermittent failure which we have observed many times whether
> on rhel or mainline kernel. But we're unable to stable reproduce it:
>
> 43 madvise06.c:201: TFAIL: less than 102400 Kb were moved to the swap cache
> ...
>
> However it does not look like a kernel issue, because SwapCached change is
> not strictly abiding by the principle of MADV_WILLNEED advice. That means it
> all depends on the kernel's specific circumstances. The value of the threshold
> is debatable at least from my point of view, its use 1/4 is not guaranteed
> 100% safe.
>
> As MADV_WILLNEED is just advice to the kernel, not a guarantee. The kernel may
> choose to ignore the advice, or may prioritize other memory management tasks
> over pre-loading the advised pages.
>
> So this patch is aimed at improving the accuracy and clarity of the test results.
> Specifically, the use of two separate variables to track the results of different
> comparisons will make it easier to understand what the test is doing.
>
> Additionally, the change to report a test result of "TINFO" instead of "TFAIL"
> when the swap cache size is less than expected would be intended to indicate
> that this is an acceptable outcome.
>
> Finally, the change to the second tst_res call is intended to make the test more
> lenient, as it now passes if either no page faults occur or the swap cache size
> is larger than expected.
Why not skip to making them all TINFO?
It's undefined what action will result from MADV_WILLNEED. If it were
better for performance *not* to read in pages, then it would be valid
for the kernel to ignore it.
Yang Xu added a tag for a perf regression that it could
reproduce. However looking at the kernel commit this was first found by
stress-ng.
commit 66383800df9cbdbf3b0c34d5a51bf35bcdb72fd2
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date: Sat Nov 21 22:17:22 2020 -0800
mm: fix madvise WILLNEED performance problem
The calculation of the end page index was incorrect, leading to a
regression of 70% when running stress-ng.
With this fix, we instead see a performance improvement of 3%
I found a bug with this test, but it was causing an Oops. It wouldn't
matter if the test printed pass or fail.
So I think we are wasting our time by constantly tweaking this test.
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-02-27 12:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 4:09 [LTP] [PATCH] madvise06: Raise the bar for judging failure Li Wang
2023-02-27 11:33 ` Richard Palethorpe [this message]
2023-02-28 5:45 ` Li Wang
2023-03-02 7:41 ` [LTP] [PATCh v2] madvise06: stop throwing failure when MADV_WILLNEED is ignored Li Wang
2023-03-03 8:38 ` Petr Vorel
2023-03-08 0:18 ` Li Wang
2023-03-13 10:15 ` Richard Palethorpe
2023-03-13 10:59 ` 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=87fsarb8eb.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=efuller@redhat.com \
--cc=liuyongqiang13@huawei.com \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=pbunyan@redhat.com \
--cc=xuyang2018.jy@cn.fujitsu.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