linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shaju Abraham <shajunutanix@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org,
	Shaju Abraham <shaju.abraham@nutanix.com>
Subject: Re: [PATCH] mm/vmpressure.c: Include GFP_KERNEL flag to vmpressure
Date: Mon, 9 Mar 2020 21:02:50 +0530	[thread overview]
Message-ID: <CAGxeL8CxaeKsqEMtLMZL8mdxUXPcH6ZkpMNjUmzZJ6q603B-_g@mail.gmail.com> (raw)
In-Reply-To: <20200309115818.GK8447@dhcp22.suse.cz>

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

On Mon, Mar 9, 2020 at 5:28 PM Michal Hocko <mhocko@kernel.org> wrote:

> On Mon 09-03-20 11:31:41, Shaju Abraham wrote:
> > The VM pressure notification flags have excluded GFP_KERNEL with the
> > reasoning that user land will not be able to take any action in case of
> > kernel memory being low. This is not true always. Consider the case of
> > a user land program managing all the huge memory pages. By including
> > GFP_KERNEL flag whenever the kernel memory is low, pressure notification
> > can be send, and the manager process can split huge pages to satisfy
> kernel
> > memory requirement.
>
> Are you sure about this reasoning? GFP_KERNEL = __GFP_FS | __GFP_IO |
> __GFP_RECLAIM
> Two of the flags mentioned there are already listed so we are talking
> about __GFP_RECLAIM here. Including it here would be a more appropriate
> change than GFP_KERNEL btw.
>
> But still I do not really understand what is the actual problem and how
> is this patch meant to fix it. vmpressure is triggered only from the
> reclaim path which inherently requires to have __GFP_RECLAIM present
> so I fail to see how this can make any change at all. How have you
> tested it?
>
>    We have a user space application which waits on memory pressure events.
Upon receiving the
  event, the user space program will free up huge pages to make more memory
available in the
  system.
  This mechanism works fine if the memory is being consumed by other user
space applications. To
  test this, we wrote a test program which will allocate all the memory
available in the system using
  malloc() and touch the allocated pages. When the free memory level
becomes low, the pressure event
  is fired and the process gets notified about it .
  The same test is repeated with kmalloc() instead of malloc(). A test
kernel  module is developed, which
  will allocate all the   available   memory with kmalloc(GFP_KERNEL)
flag.  The OOM killer gets invoked in
  this case. The memory pressure event is not fired.
  After modifying the vmpressure.c with the attached patch, the pressure
event gets triggered.
  Swap is disabled in the system we were testing.

 Regards
 Shaju


> > This is a common scanario in cloud. Most of the host memory is reserved
> > as hugepages and can be broken down to small pages on demand. This is
> > done to minimise fragmentation so that Virtual Machine power on will be
> > successful always.
> >
> > Signed-off-by: Shaju Abraham <shaju.abraham@nutanix.com>
> > ---
> >  mm/vmpressure.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> > index 4bac22fe1aa2..7ccfb3dd8173 100644
> > --- a/mm/vmpressure.c
> > +++ b/mm/vmpressure.c
> > @@ -253,7 +253,8 @@ void vmpressure(gfp_t gfp, struct mem_cgroup *memcg,
> bool tree,
> >        * Indirect reclaim (kswapd) sets sc->gfp_mask to GFP_KERNEL, so
> >        * we account it too.
> >        */
> > -     if (!(gfp & (__GFP_HIGHMEM | __GFP_MOVABLE | __GFP_IO | __GFP_FS)))
> > +     if (!(gfp & (__GFP_HIGHMEM | __GFP_MOVABLE | __GFP_IO |
> > +                  __GFP_FS | GFP_KERNEL)))
> >               return;
> >
> >       /*
> > --
> > 2.20.1
> >
>
> --
> Michal Hocko
> SUSE Labs
>

[-- Attachment #2: Type: text/html, Size: 4219 bytes --]

  reply	other threads:[~2020-03-09 15:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 11:31 [PATCH] mm/vmpressure.c: Include GFP_KERNEL flag to vmpressure Shaju Abraham
2020-03-09 11:58 ` Michal Hocko
2020-03-09 15:32   ` Shaju Abraham [this message]
2020-03-09 16:12     ` Michal Hocko
2020-03-10  7:39       ` Shaju Abraham

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=CAGxeL8CxaeKsqEMtLMZL8mdxUXPcH6ZkpMNjUmzZJ6q603B-_g@mail.gmail.com \
    --to=shajunutanix@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=shaju.abraham@nutanix.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;
as well as URLs for NNTP newsgroup(s).