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