ltp.lists.linux.it archive mirror
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).