All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Shi <shy828301@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: zokeefe@google.com, akpm@linux-foundation.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [v2 PATCH 1/2] mm: khugepaged: allow page allocation fallback to eligible nodes
Date: Fri, 4 Nov 2022 13:40:46 -0700	[thread overview]
Message-ID: <CAHbLzkqzHmRtk-46KuBGM6swQe4r20_LtSku-CZvmf+gxOhKCg@mail.gmail.com> (raw)
In-Reply-To: <Y2VuRplhVmKiabR9@dhcp22.suse.cz>

On Fri, Nov 4, 2022 at 12:55 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Fri 04-11-22 10:37:39, Yang Shi wrote:
> > On Fri, Nov 4, 2022 at 1:32 AM Michal Hocko <mhocko@suse.com> wrote:
> > >
> > > On Thu 03-11-22 14:36:40, Yang Shi wrote:
> > > [...]
> > > > So use nodemask to record the nodes which have the same hit record, the
> > > > hugepage allocation could fallback to those nodes.  And remove
> > > > __GFP_THISNODE since it does disallow fallback.  And if nodemask is
> > > > empty (no node is set), it means there is one single node has the most
> > > > hist record, the nodemask approach actually behaves like __GFP_THISNODE.
> > > >
> > > > Reported-by: syzbot+0044b22d177870ee974f@syzkaller.appspotmail.com
> > > > Suggested-by: Zach O'Keefe <zokeefe@google.com>
> > > > Suggested-by: Michal Hocko <mhocko@suse.com>
> > > > Signed-off-by: Yang Shi <shy828301@gmail.com>
> > > > ---
> > > >  mm/khugepaged.c | 32 ++++++++++++++------------------
> > > >  1 file changed, 14 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > index ea0d186bc9d4..572ce7dbf4b0 100644
> > > > --- a/mm/khugepaged.c
> > > > +++ b/mm/khugepaged.c
> > > > @@ -97,8 +97,8 @@ struct collapse_control {
> > > >       /* Num pages scanned per node */
> > > >       u32 node_load[MAX_NUMNODES];
> > > >
> > > > -     /* Last target selected in hpage_collapse_find_target_node() */
> > > > -     int last_target_node;
> > > > +     /* nodemask for allocation fallback */
> > > > +     nodemask_t alloc_nmask;
> > >
> > > This will eat another 1k on the stack on most configurations
> > > (NODE_SHIFT=10). Along with 4k of node_load this is quite a lot even
> > > on shallow call chains like madvise resp. khugepaged.  I would just
> > > add a follow up patch which changes both node_load and alloc_nmask to
> > > dynamically allocated objects.
> >
> > The collapse_control is allocated by kmalloc dynamically for
> > MADV_COLLAPSE path, and defined as a global variable for khugepaged
> > (khugepaged_collapse_control). So it is not on stack.
>
> Dang, I must have been blind because I _think_ I have seen it as a local
> stack defined. Maybe I just implicitly put that to the same bucket as
> othe $foo_control (e.g. scan_control, oom_control etc) which leave on the
> stack usually. Sorry about the confusion. Sorry for the noise.

It doesn't matter. It was not put on the stack due to its size when
Zach was adding MADV_COLLAPSE.

>
> Acked-by: Michal Hocko <mhocko@suse.com>

Thanks.

> --
> Michal Hocko
> SUSE Labs

      reply	other threads:[~2022-11-04 20:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 21:36 [v2 PATCH 1/2] mm: khugepaged: allow page allocation fallback to eligible nodes Yang Shi
2022-11-03 21:36 ` [v2 PATCH 2/2] mm: don't warn if the node is offlined Yang Shi
2022-11-04  9:35   ` Michal Hocko
2022-11-04  9:56     ` Michal Hocko
2022-11-04 17:42       ` Yang Shi
2022-11-04 19:51         ` Michal Hocko
2022-11-04 20:52           ` Yang Shi
2022-11-07  7:55             ` Michal Hocko
2022-11-07 18:48               ` Yang Shi
2022-11-08  0:58                 ` Zach O'Keefe
2022-11-03 23:58 ` [v2 PATCH 1/2] mm: khugepaged: allow page allocation fallback to eligible nodes Zach O'Keefe
2022-11-04 20:39   ` Yang Shi
2022-11-04  8:32 ` Michal Hocko
2022-11-04 17:37   ` Yang Shi
2022-11-04 19:55     ` Michal Hocko
2022-11-04 20:40       ` Yang Shi [this message]

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=CAHbLzkqzHmRtk-46KuBGM6swQe4r20_LtSku-CZvmf+gxOhKCg@mail.gmail.com \
    --to=shy828301@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.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.