All of lore.kernel.org
 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 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.