All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Shi <shy828301@gmail.com>
To: "Zach O'Keefe" <zokeefe@google.com>
Cc: kernel test robot <lkp@intel.com>,
	Alex Shi <alex.shi@linux.alibaba.com>,
	 David Hildenbrand <david@redhat.com>,
	David Rientjes <rientjes@google.com>,
	 Matthew Wilcox <willy@infradead.org>,
	Michal Hocko <mhocko@suse.com>,
	 Pasha Tatashin <pasha.tatashin@soleen.com>,
	Peter Xu <peterx@redhat.com>,
	 Rongwei Wang <rongwei.wang@linux.alibaba.com>,
	SeongJae Park <sj@kernel.org>,  Song Liu <songliubraving@fb.com>,
	Vlastimil Babka <vbabka@suse.cz>, Zi Yan <ziy@nvidia.com>,
	 Linux MM <linux-mm@kvack.org>,
	kbuild-all@lists.01.org,  Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Arnd Bergmann <arnd@arndb.de>,
	Axel Rasmussen <axelrasmussen@google.com>,
	 Chris Kennelly <ckennelly@google.com>,
	Chris Zankel <chris@zankel.net>, Helge Deller <deller@gmx.de>,
	 Hugh Dickins <hughd@google.com>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	 "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Jens Axboe <axboe@kernel.dk>,
	 "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Matt Turner <mattst88@gmail.com>,
	 Max Filippov <jcmvbkbc@gmail.com>,
	Miaohe Lin <linmiaohe@huawei.com>
Subject: Re: [PATCH v6 03/15] mm/khugepaged: add struct collapse_control
Date: Mon, 6 Jun 2022 14:22:41 -0700	[thread overview]
Message-ID: <CAHbLzkpfGH8U88w_tiv9B1x7p7nH2Ak4KSR2PGjBYaVp-08fmw@mail.gmail.com> (raw)
In-Reply-To: <CAHbLzkrA7PfbLMOu3Z2JHyx_8Njd+Oj_voSOys5tmwOHCW=WQQ@mail.gmail.com>

On Mon, Jun 6, 2022 at 1:20 PM Yang Shi <shy828301@gmail.com> wrote:
>
> On Mon, Jun 6, 2022 at 9:40 AM Zach O'Keefe <zokeefe@google.com> wrote:
> >
> > On Sun, Jun 5, 2022 at 7:42 PM kernel test robot <lkp@intel.com> wrote:
> > >
> > > Hi Zach,
> > >
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test WARNING on akpm-mm/mm-everything]
> > >
> > > url:    https://github.com/intel-lab-lkp/linux/commits/Zach-O-Keefe/mm-userspace-hugepage-collapse/20220606-012953
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> > > config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20220606/202206060911.I8rRqGwC-lkp@intel.com/config)
> > > compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
> > > reproduce (this is a W=1 build):
> > >         # https://github.com/intel-lab-lkp/linux/commit/d87b6065d6050b89930cca0814921aca7c269286
> > >         git remote add linux-review https://github.com/intel-lab-lkp/linux
> > >         git fetch --no-tags linux-review Zach-O-Keefe/mm-userspace-hugepage-collapse/20220606-012953
> > >         git checkout d87b6065d6050b89930cca0814921aca7c269286
> > >         # save the config file
> > >         mkdir build_dir && cp config build_dir/.config
> > >         make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
> > >
> > > If you fix the issue, kindly add following tag where applicable
> > > Reported-by: kernel test robot <lkp@intel.com>
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > >    mm/khugepaged.c: In function 'khugepaged':
> > > >> mm/khugepaged.c:2284:1: warning: the frame size of 4160 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> > >     2284 | }
> > >          | ^
> >
> > Thanks lkp@intel.com.
> >
> > This is due to config with:
> >
> > CONFIG_FRAME_WARN=2048
> > CONFIG_NODES_SHIFT=10
> >
> > Where struct collapse_control has a member int
> > node_load[MAX_NUMNODES], and we stack allocate one.
> >
> > Is this a configuration that needs to be supported? 1024 nodes seems
> > like a lot and I'm not sure if these configs are randomly generated or
> > are reminiscent of real systems.
>
> I don't have a better idea other than moving it out of the
> collapse_control struct. You may consider changing node_load to two
> dimensions, for example:
>
> node_load[2][MAX_NUMNODES], then define:
> enum {
>     /* khugepaged */
>     COLLAPSE_ASYNC,
>     /* MADV_COLLAPSE */
>     COLLAPSE_SYNC
> }
>
> Then khugepaged and MADV_COLLAPSE get their dedicated node_load respectively.

Sorry, I just realized this won't work for MADV_COLLAPSE since
multiple processes may call it at the same time. We may consider
allocating it dynamically. Have node_load the last element of
collapse_control struct, then do:
for_each_node(node)
    kmalloc(sizeof(int), GFP_KERNEL);

MADV_COLLAPSE or khugepaged could just fail if it fails since THP
allocation is unlikely to succeed in this case. But not sure if it is
worth the complexity rather than just killing it.

>
> The more aggressive approach may be just killing node_load, but I'm
> not sure what impact it may incur.
>
> >
> > Thanks,
> > Zach
> >
> > >
> > > vim +2284 mm/khugepaged.c
> > >
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2261
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2262  static int khugepaged(void *none)
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2263  {
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2264      struct mm_slot *mm_slot;
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2265      struct collapse_control cc = {
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2266              .last_target_node = NUMA_NO_NODE,
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2267      };
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2268
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2269      set_freezable();
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2270      set_user_nice(current, MAX_NICE);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2271
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2272      while (!kthread_should_stop()) {
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2273              khugepaged_do_scan(&cc);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2274              khugepaged_wait_work();
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2275      }
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2276
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2277      spin_lock(&khugepaged_mm_lock);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2278      mm_slot = khugepaged_scan.mm_slot;
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2279      khugepaged_scan.mm_slot = NULL;
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2280      if (mm_slot)
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2281              collect_mm_slot(mm_slot);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2282      spin_unlock(&khugepaged_mm_lock);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2283      return 0;
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26 @2284  }
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2285
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://01.org/lkp
> > >


WARNING: multiple messages have this Message-ID (diff)
From: Yang Shi <shy828301@gmail.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH v6 03/15] mm/khugepaged: add struct collapse_control
Date: Mon, 06 Jun 2022 14:22:41 -0700	[thread overview]
Message-ID: <CAHbLzkpfGH8U88w_tiv9B1x7p7nH2Ak4KSR2PGjBYaVp-08fmw@mail.gmail.com> (raw)
In-Reply-To: <CAHbLzkrA7PfbLMOu3Z2JHyx_8Njd+Oj_voSOys5tmwOHCW=WQQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5379 bytes --]

On Mon, Jun 6, 2022 at 1:20 PM Yang Shi <shy828301@gmail.com> wrote:
>
> On Mon, Jun 6, 2022 at 9:40 AM Zach O'Keefe <zokeefe@google.com> wrote:
> >
> > On Sun, Jun 5, 2022 at 7:42 PM kernel test robot <lkp@intel.com> wrote:
> > >
> > > Hi Zach,
> > >
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test WARNING on akpm-mm/mm-everything]
> > >
> > > url:    https://github.com/intel-lab-lkp/linux/commits/Zach-O-Keefe/mm-userspace-hugepage-collapse/20220606-012953
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> > > config: x86_64-rhel-8.3 (https://download.01.org/0day-ci/archive/20220606/202206060911.I8rRqGwC-lkp(a)intel.com/config)
> > > compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
> > > reproduce (this is a W=1 build):
> > >         # https://github.com/intel-lab-lkp/linux/commit/d87b6065d6050b89930cca0814921aca7c269286
> > >         git remote add linux-review https://github.com/intel-lab-lkp/linux
> > >         git fetch --no-tags linux-review Zach-O-Keefe/mm-userspace-hugepage-collapse/20220606-012953
> > >         git checkout d87b6065d6050b89930cca0814921aca7c269286
> > >         # save the config file
> > >         mkdir build_dir && cp config build_dir/.config
> > >         make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
> > >
> > > If you fix the issue, kindly add following tag where applicable
> > > Reported-by: kernel test robot <lkp@intel.com>
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > >    mm/khugepaged.c: In function 'khugepaged':
> > > >> mm/khugepaged.c:2284:1: warning: the frame size of 4160 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> > >     2284 | }
> > >          | ^
> >
> > Thanks lkp(a)intel.com.
> >
> > This is due to config with:
> >
> > CONFIG_FRAME_WARN=2048
> > CONFIG_NODES_SHIFT=10
> >
> > Where struct collapse_control has a member int
> > node_load[MAX_NUMNODES], and we stack allocate one.
> >
> > Is this a configuration that needs to be supported? 1024 nodes seems
> > like a lot and I'm not sure if these configs are randomly generated or
> > are reminiscent of real systems.
>
> I don't have a better idea other than moving it out of the
> collapse_control struct. You may consider changing node_load to two
> dimensions, for example:
>
> node_load[2][MAX_NUMNODES], then define:
> enum {
>     /* khugepaged */
>     COLLAPSE_ASYNC,
>     /* MADV_COLLAPSE */
>     COLLAPSE_SYNC
> }
>
> Then khugepaged and MADV_COLLAPSE get their dedicated node_load respectively.

Sorry, I just realized this won't work for MADV_COLLAPSE since
multiple processes may call it at the same time. We may consider
allocating it dynamically. Have node_load the last element of
collapse_control struct, then do:
for_each_node(node)
    kmalloc(sizeof(int), GFP_KERNEL);

MADV_COLLAPSE or khugepaged could just fail if it fails since THP
allocation is unlikely to succeed in this case. But not sure if it is
worth the complexity rather than just killing it.

>
> The more aggressive approach may be just killing node_load, but I'm
> not sure what impact it may incur.
>
> >
> > Thanks,
> > Zach
> >
> > >
> > > vim +2284 mm/khugepaged.c
> > >
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2261
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2262  static int khugepaged(void *none)
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2263  {
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2264      struct mm_slot *mm_slot;
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2265      struct collapse_control cc = {
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2266              .last_target_node = NUMA_NO_NODE,
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2267      };
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2268
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2269      set_freezable();
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2270      set_user_nice(current, MAX_NICE);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2271
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2272      while (!kthread_should_stop()) {
> > > d87b6065d6050b Zach O'Keefe       2022-06-03  2273              khugepaged_do_scan(&cc);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2274              khugepaged_wait_work();
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2275      }
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2276
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2277      spin_lock(&khugepaged_mm_lock);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2278      mm_slot = khugepaged_scan.mm_slot;
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2279      khugepaged_scan.mm_slot = NULL;
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2280      if (mm_slot)
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2281              collect_mm_slot(mm_slot);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2282      spin_unlock(&khugepaged_mm_lock);
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2283      return 0;
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26 @2284  }
> > > b46e756f5e4703 Kirill A. Shutemov 2016-07-26  2285
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://01.org/lkp
> > >

  reply	other threads:[~2022-06-06 21:22 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-04  0:39 [PATCH v6 00/15] mm: userspace hugepage collapse Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 01/15] mm: khugepaged: don't carry huge page to the next loop for !CONFIG_NUMA Zach O'Keefe
2022-06-06 18:25   ` Yang Shi
2022-06-29 20:49   ` Peter Xu
2022-06-30  1:15     ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 02/15] mm/khugepaged: record SCAN_PMD_MAPPED when scan_pmd() finds THP Zach O'Keefe
2022-06-06 20:45   ` Yang Shi
2022-06-07 16:01     ` Zach O'Keefe
2022-06-07 19:32       ` Zach O'Keefe
2022-06-07 21:27         ` Yang Shi
2022-06-08  0:27           ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 03/15] mm/khugepaged: add struct collapse_control Zach O'Keefe
2022-06-06  2:41   ` kernel test robot
2022-06-06 16:40     ` Zach O'Keefe
2022-06-06 16:40       ` Zach O'Keefe
2022-06-06 20:20       ` Yang Shi
2022-06-06 20:20         ` Yang Shi
2022-06-06 21:22         ` Yang Shi [this message]
2022-06-06 21:22           ` Yang Shi
2022-06-06 22:23       ` Andrew Morton
2022-06-06 22:23         ` Andrew Morton
2022-06-06 23:53         ` Yang Shi
2022-06-06 23:53           ` Yang Shi
2022-06-08  0:42           ` Zach O'Keefe
2022-06-08  0:42             ` Zach O'Keefe
2022-06-08  1:00             ` Yang Shi
2022-06-08  1:00               ` Yang Shi
2022-06-08  1:06               ` Zach O'Keefe
2022-06-08  1:06                 ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 04/15] mm/khugepaged: dedup and simplify hugepage alloc and charging Zach O'Keefe
2022-06-06 20:50   ` Yang Shi
2022-06-29 21:58   ` Peter Xu
2022-06-30 20:14     ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 05/15] mm/khugepaged: make allocation semantics context-specific Zach O'Keefe
2022-06-06 20:58   ` Yang Shi
2022-06-07 19:56     ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 06/15] mm/khugepaged: pipe enum scan_result codes back to callers Zach O'Keefe
2022-06-06 22:39   ` Yang Shi
2022-06-07  0:17     ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 07/15] mm/khugepaged: add flag to ignore khugepaged heuristics Zach O'Keefe
2022-06-06 22:51   ` Yang Shi
2022-06-04  0:39 ` [PATCH v6 08/15] mm/khugepaged: add flag to ignore THP sysfs enabled Zach O'Keefe
2022-06-06 23:02   ` Yang Shi
     [not found]   ` <YrzehlUoo2iMMLC2@xz-m1.local>
     [not found]     ` <CAAa6QmRXD5KboM8=ZZRPThOmcLEPtxzf0XyjkCeY_vgR7VOPqg@mail.gmail.com>
2022-06-30  2:32       ` Peter Xu
2022-06-30 14:17         ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 09/15] mm/madvise: introduce MADV_COLLAPSE sync hugepage collapse Zach O'Keefe
2022-06-06 23:53   ` Yang Shi
2022-06-07 22:48     ` Zach O'Keefe
2022-06-08  0:39       ` Yang Shi
2022-06-09 17:35         ` Zach O'Keefe
2022-06-09 18:51           ` Yang Shi
2022-06-10 14:51             ` Zach O'Keefe
2022-06-04  0:39 ` [PATCH v6 10/15] mm/khugepaged: rename prefix of shared collapse functions Zach O'Keefe
2022-06-06 23:56   ` Yang Shi
2022-06-07  0:31     ` Zach O'Keefe
2022-06-04  0:40 ` [PATCH v6 11/15] mm/madvise: add MADV_COLLAPSE to process_madvise() Zach O'Keefe
2022-06-07 19:14   ` Yang Shi
2022-06-04  0:40 ` [PATCH v6 12/15] selftests/vm: modularize collapse selftests Zach O'Keefe
2022-06-04  0:40 ` [PATCH v6 13/15] selftests/vm: add MADV_COLLAPSE collapse context to selftests Zach O'Keefe
2022-06-04  0:40 ` [PATCH v6 14/15] selftests/vm: add selftest to verify recollapse of THPs Zach O'Keefe
2022-06-04  0:40 ` [PATCH v6 15/15] tools headers uapi: add MADV_COLLAPSE madvise mode to tools Zach O'Keefe
2022-06-06 23:58   ` Yang Shi
2022-06-07  0:24     ` Zach O'Keefe

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=CAHbLzkpfGH8U88w_tiv9B1x7p7nH2Ak4KSR2PGjBYaVp-08fmw@mail.gmail.com \
    --to=shy828301@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=axelrasmussen@google.com \
    --cc=chris@zankel.net \
    --cc=ckennelly@google.com \
    --cc=david@redhat.com \
    --cc=deller@gmx.de \
    --cc=hughd@google.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jcmvbkbc@gmail.com \
    --cc=kbuild-all@lists.01.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mattst88@gmail.com \
    --cc=mhocko@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterx@redhat.com \
    --cc=rientjes@google.com \
    --cc=rongwei.wang@linux.alibaba.com \
    --cc=sj@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    --cc=zokeefe@google.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.