From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] madvise06: Increase reliability and diagnostic info
Date: Tue, 27 Oct 2020 13:18:00 +0000 [thread overview]
Message-ID: <877drbvmd3.fsf@suse.de> (raw)
In-Reply-To: <CAEemH2d8+5qLLKWsuf5WJeLHdv2VfPZiyM9-oW=WyH4m==h=8g@mail.gmail.com>
Hello Li,
Li Wang <liwang@redhat.com> writes:
> On Mon, Oct 26, 2020 at 8:16 PM Richard Palethorpe <rpalethorpe@suse.com>
> wrote:
>
>> When memcg.limit_in_bytes is set to PASS_THRESHOLD it's unlikely
>> swapcached will increase by more than PASS_THRESHOLD unless processes
>> in other memcgs are also increasing it. Additionally MADV_WILLNEED
>> must remove pages from memory as it adds more so that the first page
>> may not be in memory by the time the last page is faulted if the
>> amount exceeds the memory limit (which it does because CHUNK_SZ >
>> PASS_THRESSHOLD). Worse if pages are faulted in a non-linear way, or
>> the process must access some other pages, then there is no guarantee
>> which parts of the range will be resident in memory. This results in
>> spurious test failures.
>>
>> To solve this we can set PASS_THRESHOLD to 1/4 of CHUNK_SZ and
>> memcg.limit_in_bytes to 1/2 of CHUNK_SZ (MEM_LIMIT), then mark
>> MEM_LIMIT bytes as needed. That way the amount in the SwapCache will
>> easily be more than the threshold. Secondly we can run madvise again
>> on PASS_THRESHOLD bytes and check that dirtying all of these does not
>> result in too many page faults. We also run the second test on every
>> occasion to ensure the test code itself is still valid. If the
>> original bug is present then both tests fail.
>>
>> Finally this prints more diagnostic information to help with debugging
>> the test.
>>
>> While debugging the test a kernel bug was found in 5.9 which effects
>> CGroupV1 when use_hierarchy=0. This is unlikely to effect many users,
>> but a fix is pending and will be referenced in the test when
>> available. It is recommended that you set use_hierarchy=1.
>>
>
> Great, we could add the commit info as well after patch merging in the
> mainline kernel.
>
>
>> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
>>
> Reviewed-by: Li Wang <liwang@redhat.com>
>
> This improvement makes sense to me apart from a tiny syntax error below.
>
> One additional comment, I found this test now only run with CGroupV1,
> and maybe we could make use of the LTP-cgroup new library after we
> updating that(tst_cgroup.c) to make it works well with CGroupV2.
+1
Also we may need to run tests with and without use_hierarchy, plus other
configurations.
>
> ---
>> testcases/kernel/syscalls/madvise/madvise06.c | 107 ++++++++++++++----
>> 1 file changed, 84 insertions(+), 23 deletions(-)
>>
>> diff --git a/testcases/kernel/syscalls/madvise/madvise06.c
>> b/testcases/kernel/syscalls/madvise/madvise06.c
>> index f76f3f6aa..3e70da37e 100644
>> --- a/testcases/kernel/syscalls/madvise/madvise06.c
>> +++ b/testcases/kernel/syscalls/madvise/madvise06.c
>> @@ -19,6 +19,23 @@
>> * Date: Thu May 22 11:54:17 2014 -0700
>> *
>> * mm: madvise: fix MADV_WILLNEED on shmem swapouts
>> + *
>> + * Two checks are performed, the first looks at how SwapCache
>> + * changes during madvise. When the pages are dirtied, about half
>> + * will be accounted for under Cached and the other half will be
>> + * moved into Swap. When madvise is run it will cause the pages
>> + * under Cached to also be moved to Swap while rotating the pages
>> + * already in Swap into SwapCached. So we expect that SwapCached has
>> + * roughly MEM_LIMIT bytes added to it, but for reliability the
>> + * PASS_THRESHOLD is much lower than that.
>> + *
>> + * Secondly we run madvise again, but only on the first
>> + * PASS_THRESHOLD bytes to ensure these are entirely in RAM. Then we
>> + * dirty these pages and check there were (almost) no page
>> + * faults. Two faults are allowed incase some tasklet or something
>> + * else unexpected, but irrelevant procedure, registers a fault to
>> + * our process.
>> + *
>> */
>>
>> #include <errno.h>
>> @@ -28,8 +45,10 @@
>> #include "tst_test.h"
>>
>> #define CHUNK_SZ (400*1024*1024L)
>> -#define CHUNK_PAGES (CHUNK_SZ / pg_sz)
>> +#define MEM_LIMIT (CHUNK_SZ / 2)
>> +#define MEMSW_LIMIT (2 * CHUNK_SZ)
>> #define PASS_THRESHOLD (CHUNK_SZ / 4)
>> +#define PASS_THRESHOLD_KB (PASS_THRESHOLD / 1024)
>>
>> #define MNT_NAME "memory"
>> #define GROUP_NAME "madvise06"
>> @@ -37,12 +56,39 @@
>> static const char drop_caches_fname[] = "/proc/sys/vm/drop_caches";
>> static int pg_sz;
>>
>> +static long init_swap, init_swap_cached, init_cached;
>> +
>> static void check_path(const char *path)
>> {
>> if (access(path, R_OK | W_OK))
>> tst_brk(TCONF, "file needed: %s\n", path);
>> }
>>
>> +#define READ_CGMEM(item) \
>> + ({long tst_rval; \
>> + SAFE_FILE_LINES_SCANF(MNT_NAME"/"GROUP_NAME"/memory."item, \
>> + "%ld", \
>> + &tst_rval); \
>> + tst_rval;})
>> +
>> +static void meminfo_diag(const char *point)
>> +{
>> + FILE_PRINTF("/proc/sys/vm/stat_refresh", "1");
>> + tst_res(TINFO, point);
>>
>
> Here is a syntax error, to fix it as:
> tst_res(TINFO, "%s", point);
Thanks!
--
Thank you,
Richard.
next prev parent reply other threads:[~2020-10-27 13:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 12:16 [LTP] [PATCH] madvise06: Increase reliability and diagnostic info Richard Palethorpe
2020-10-27 12:38 ` Li Wang
2020-10-27 13:18 ` Richard Palethorpe [this message]
2020-10-27 13:23 ` [LTP] [PATCH v2] " Richard Palethorpe
[not found] ` <CAEemH2cevcmS1Cq-t0667CwQmxWL=6YNdBzvKNem2YV1E5EVSg@mail.gmail.com>
2020-11-02 6:53 ` Li Wang
[not found] <20240318032447.1573-1-wangkaiyuan@inspur.com>
2024-03-18 6:44 ` [LTP] [PATCH] " 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=877drbvmd3.fsf@suse.de \
--to=rpalethorpe@suse.de \
--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.