Linux Test Project
 help / color / mirror / Atom feed
From: Tarun Sahu <tsahu@linux.ibm.com>
To: Li Wang <liwang@redhat.com>
Cc: geetika@linux.ibm.com, sbhat@linux.ibm.com,
	aneesh.kumar@linux.ibm.com, vaibhav@linux.ibm.com,
	ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3 3/4] Hugetlb: Migrating libhugetlbfs chunk-overcommit
Date: Mon, 31 Oct 2022 16:49:28 +0530	[thread overview]
Message-ID: <20221031111928.kreic4jn2jvjs2od@tarunpc> (raw)
In-Reply-To: <CAEemH2eorzpq=duqXbNLy3C0Ysxjo6fe5Ne7XqgArDQuKZHB6w@mail.gmail.com>

On Oct 31 2022, Li Wang wrote:
> On Sat, Oct 29, 2022 at 3:14 PM Tarun Sahu <tsahu@linux.ibm.com> wrote:
> 
> > Migrating the libhugetlbfs/testcases/chunk-overcommit.c test
> >
> > Test Description: Some kernel versions after hugepage demand allocation was
> > added used a dubious heuristic to check if there was enough hugepage space
> > available for a given mapping.  The number of not-already-instantiated
> > pages in the mapping was compared against the total hugepage free pool. It
> > was very easy to confuse this heuristic into overcommitting by allocating
> > hugepage memory in chunks, each less than the total available pool size but
> > together more than available.  This would generally lead to OOM SIGKILLs of
> > one process or another when it tried to instantiate pages beyond the
> > available pool.
> >
> > Signed-off-by: Tarun Sahu <tsahu@linux.ibm.com>
> > ---
> >  runtest/hugetlb                               |   1 +
> >  testcases/kernel/mem/.gitignore               |   1 +
> >  .../kernel/mem/hugetlb/hugemmap/hugemmap08.c  | 144 ++++++++++++++++++
> >  3 files changed, 146 insertions(+)
> >  create mode 100644 testcases/kernel/mem/hugetlb/hugemmap/hugemmap08.c
> >
> > diff --git a/runtest/hugetlb b/runtest/hugetlb
> > index f7ff81cb3..664f18827 100644
> > --- a/runtest/hugetlb
> > +++ b/runtest/hugetlb
> > @@ -4,6 +4,7 @@ hugemmap04 hugemmap04
> >  hugemmap05 hugemmap05
> >  hugemmap06 hugemmap06
> >  hugemmap07 hugemmap07
> > +hugemmap08 hugemmap08
> >  hugemmap05_1 hugemmap05 -m
> >  hugemmap05_2 hugemmap05 -s
> >  hugemmap05_3 hugemmap05 -s -m
> > diff --git a/testcases/kernel/mem/.gitignore
> > b/testcases/kernel/mem/.gitignore
> > index df5256ec8..003ce422b 100644
> > --- a/testcases/kernel/mem/.gitignore
> > +++ b/testcases/kernel/mem/.gitignore
> > @@ -5,6 +5,7 @@
> >  /hugetlb/hugemmap/hugemmap05
> >  /hugetlb/hugemmap/hugemmap06
> >  /hugetlb/hugemmap/hugemmap07
> > +/hugetlb/hugemmap/hugemmap08
> >  /hugetlb/hugeshmat/hugeshmat01
> >  /hugetlb/hugeshmat/hugeshmat02
> >  /hugetlb/hugeshmat/hugeshmat03
> > diff --git a/testcases/kernel/mem/hugetlb/hugemmap/hugemmap08.c
> > b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap08.c
> > new file mode 100644
> > index 000000000..61db030d5
> > --- /dev/null
> > +++ b/testcases/kernel/mem/hugetlb/hugemmap/hugemmap08.c
> > @@ -0,0 +1,144 @@
> > +// SPDX-License-Identifier: LGPL-2.1-or-later
> > +/*
> > + * Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.
> > + * Author: David Gibson & Adam Litke
> > + */
> > +
> > +/*\
> > + * [Description]
> > + *
> > + * Chunk Overcommit:
> > + * Some kernel versions after hugepage demand allocation was added used a
> > + * dubious heuristic to check if there was enough hugepage space available
> > + * for a given mapping.  The number of not-already-instantiated pages in
> > + * the mapping was compared against the total hugepage free pool. It was
> > + * very easy to confuse this heuristic into overcommitting by allocating
> > + * hugepage memory in chunks, each less than the total available pool size
> > + * but together more than available.  This would generally lead to OOM
> > + * SIGKILLs of one process or another when it tried to instantiate pages
> > + * beyond the available pool.
> > + *
> > + * HISTORY
> > + *
> > + */
> > +
> > +#define _GNU_SOURCE
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <sys/mount.h>
> > +#include <limits.h>
> > +#include <sys/param.h>
> > +#include <sys/types.h>
> > +#include <sys/wait.h>
> > +#include <signal.h>
> > +
> > +#include "hugetlb.h"
> > +
> > +#define PROC_OVERCOMMIT "/proc/sys/vm/nr_overcommit_hugepages"
> > +#define WITH_OVERCOMMIT 0
> > +#define WITHOUT_OVERCOMMIT 1
> > +
> > +static long hpage_size;
> > +
> > +static void test_chunk_overcommit(void)
> > +{
> > +       unsigned long totpages, chunk1, chunk2;
> > +       void *p, *q;
> > +       pid_t child;
> > +       int status;
> > +
> > +       totpages = SAFE_READ_MEMINFO("HugePages_Free:");
> > +
> > +       chunk1 = (totpages / 2) + 1;
> > +       chunk2 = totpages - chunk1 + 1;
> > +
> > +       tst_res(TINFO, "Free: %ld hugepages available: "
> > +              "chunk1=%ld chunk2=%ld", totpages, chunk1, chunk2);
> > +
> > +       p = SAFE_MMAP(NULL, chunk1*hpage_size, PROT_READ|PROT_WRITE,
> > MAP_SHARED,
> > +                tst_hugetlb_fd, 0);
> > +
> > +       q = mmap(NULL, chunk2*hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED,
> > +                tst_hugetlb_fd, chunk1*hpage_size);
> > +       if (q == MAP_FAILED) {
> > +               if (errno != ENOMEM) {
> > +                       tst_res(TFAIL | TERRNO, "mmap() chunk2");
> > +                       goto cleanup1;
> > +               } else {
> > +                       tst_res(TPASS, "Successful without overcommit
> > pages");
> > +                       goto cleanup1;
> > +               }
> > +       }
> > +
> > +       tst_res(TINFO, "Looks like we've overcommitted, testing...");
> > +       /* Looks like we're overcommited, but we need to confirm that
> > +        * this is bad.  We touch it all in a child process because an
> > +        * overcommit will generally lead to a SIGKILL which we can't
> > +        * handle, of course.
> > +        */
> > +       child = SAFE_FORK();
> > +
> > +       if (child == 0) {
> > +               memset(p, 0, chunk1*hpage_size);
> > +               memset(q, 0, chunk2*hpage_size);
> > +               exit(0);
> > +       }
> > +
> > +       SAFE_WAITPID(child, &status, 0);
> > +
> > +       if (WIFSIGNALED(status)) {
> > +               tst_res(TFAIL, "Killed by signal '%s' due to overcommit",
> > +                    tst_strsig(WTERMSIG(status)));
> > +               goto cleanup2;
> > +       }
> > +
> > +       tst_res(TPASS, "Successful with overcommit pages");
> > +
> > +cleanup2:
> > +       SAFE_MUNMAP(q, chunk2*hpage_size);
> > +
> > +cleanup1:
> > +       SAFE_MUNMAP(p, chunk1*hpage_size);
> > +       SAFE_FTRUNCATE(tst_hugetlb_fd, 0);
> > +}
> > +
> > +static void run_test(unsigned int test_type)
> > +{
> > +       unsigned long saved_oc_hugepages;
> > +
> > +       SAFE_FILE_SCANF(PROC_OVERCOMMIT, "%ld", &saved_oc_hugepages);
> >
> 
> There is unnecessary to read PROC_OVERCOMMIT value again,
> we already save/restore it in struct tst_path_val[], so here we
> can set it directly to what we expected no matter if the original is 0 or 2.
> 
> static void run_test(unsigned int test_type)
> {
>         switch (test_type) {
>         case WITHOUT_OVERCOMMIT:
>                 tst_res(TINFO, "Without overcommit testing...");
>                 SAFE_FILE_PRINTF(PROC_OVERCOMMIT, "%d", 0);
>                 break;
>         case WITH_OVERCOMMIT:
>                 tst_res(TINFO, "With overcommit testing...");
>                 SAFE_FILE_PRINTF(PROC_OVERCOMMIT, "%d", 2);
>                 break;
>     }
>     test_chunk_overcommit();
> }
> 
Yeah, Missed it. Will update it.
> 
> 
> > +       switch (test_type) {
> > +       case WITHOUT_OVERCOMMIT:
> > +               tst_res(TINFO, "Without overcommit testing...");
> > +               if (saved_oc_hugepages > 0)
> > +                       SAFE_FILE_PRINTF(PROC_OVERCOMMIT, "%d", 0);
> > +               break;
> > +       case WITH_OVERCOMMIT:
> > +               tst_res(TINFO, "With overcommit testing...");
> > +               if (saved_oc_hugepages == 0)
> > +                       SAFE_FILE_PRINTF(PROC_OVERCOMMIT, "%d", 2);
> > +               break;
> > +       }
> > +       test_chunk_overcommit();
> > +}
> > +
> > +static void setup(void)
> > +{
> > +       hpage_size = SAFE_READ_MEMINFO("Hugepagesize:")*1024;
> > +}
> > +
> > +static struct tst_test test = {
> > +       .needs_root = 1,
> > +       .needs_hugetlbfs = 1,
> > +       .needs_unlinked_hugetlb_file = 1,
> > +       .forks_child = 1,
> > +       .save_restore = (const struct tst_path_val[]) {
> > +               {PROC_OVERCOMMIT, NULL},
> > +               {}
> > +       },
> > +       .tcnt = 2,
> > +       .setup = setup,
> > +       .test = run_test,
> > +       .hugepages = {3, TST_NEEDS},
> > +};
> > +
> > --
> > 2.31.1
> >
> >
> > --
> > Mailing list info: https://lists.linux.it/listinfo/ltp
> >
> >
> 
> -- 
> Regards,
> Li Wang

> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2022-10-31 11:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-29  7:13 [LTP] [PATCH v3 0/4] Hugetlb:Migrating the libhugetlbfs tests Tarun Sahu
2022-10-29  7:13 ` [LTP] [PATCH v3 1/4] Hugetlb: Add new tst_test options for hugeltb test support Tarun Sahu
2022-10-31  3:39   ` Li Wang
2022-10-31 11:08     ` Tarun Sahu
2022-10-31 14:49     ` Cyril Hrubis
2022-10-31 14:56     ` Cyril Hrubis
2022-10-31 18:02       ` Tarun Sahu
2022-11-01  2:05       ` Li Wang
2022-10-31 14:47   ` Cyril Hrubis
2022-10-31 19:25     ` Tarun Sahu
2022-11-02 13:38       ` Cyril Hrubis
2022-10-29  7:13 ` [LTP] [PATCH v3 2/4] Hugetlb: Migrating libhugetlbfs brk_near_huge Tarun Sahu
2022-10-29  7:13 ` [LTP] [PATCH v3 3/4] Hugetlb: Migrating libhugetlbfs chunk-overcommit Tarun Sahu
2022-10-31  7:34   ` Li Wang
2022-10-31 11:19     ` Tarun Sahu [this message]
2022-10-29  7:13 ` [LTP] [PATCH v3 4/4] Hugetlb: Migrating libhugetlbfs corrupt-by-cow-opt Tarun Sahu

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=20221031111928.kreic4jn2jvjs2od@tarunpc \
    --to=tsahu@linux.ibm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=geetika@linux.ibm.com \
    --cc=liwang@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=sbhat@linux.ibm.com \
    --cc=vaibhav@linux.ibm.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