public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	linux-mm@kvack.org, Vishal Moola <vishal.moola@gmail.com>,
	Baoquan He <bhe@redhat.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY
Date: Wed, 11 Mar 2026 13:45:38 +0100	[thread overview]
Message-ID: <abFj8gwNrpv0qQsJ@tiehlicka> (raw)
In-Reply-To: <abEq9eX3-7yeNHVB@pc636>

On Wed 11-03-26 09:42:29, Uladzislau Rezki wrote:
> On Tue, Mar 10, 2026 at 03:59:14PM -0700, Andrew Morton wrote:
> > On Mon, 2 Mar 2026 19:51:25 +0100 Michal Hocko <mhocko@suse.com> wrote:
> > 
> > > > I wouldn't do this because:
> > > > 
> > > > 1. it makes the __GFP_RETRY_MAYFAIL allocations unreliable.
> > > 
> > > __GFP_RETRY_MAYFAIL doesn't provide any reliability. It just promisses
> > > to not OOM while trying hard. I believe this implementation doesn't
> > > break that promise.
> > > 
> > > > 2. The comment at memalloc_noreclaim_save says that it may deplete memory 
> > > > reserves: "This should only be used when the caller guarantees the 
> > > > allocation will allow more memory to be freed very shortly, i.e. it needs 
> > > > to allocate some memory in the process of freeing memory, and cannot 
> > > > reclaim due to potential recursion."
> > > 
> > > yes, this allocation clearly doesn't guaratee to free more memory. That
> > > comment is rather dated. Anyway, the crux is to make sure that the
> > > allocation is not unbound. The idea behind this decision is that the
> > > page tables are only a tiny fraction of the resulting memory allocated.
> > > Moreover this virtually allocated space is recycled so over time there
> > > should be less and less of page tables allocated as well.
> > >  
> > > > I think that the cleanest solution to this problem would be to get rid of 
> > > > PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO and instead introduce two per-thread 
> > > > variables "gfp_t set_flags" and "gfp_t clear_flags" and set and clear gfp 
> > > > flags according to them in the allocator: "gfp = (gfp | 
> > > > current->set_flags) & ~current->clear_flags";
> > > 
> > > We've been through discussions like this one way too many times and the
> > > conclusion is that, no this will not work. The gfp space we have and
> > > need to support without rewriting a large part of the kernel is simply
> > > incompatible with a more sane interface. Yeah, I hate that as well but
> > > here we are. We need to be creative to keep sensible and not introduce
> > > even more weirdness to the interface.
> > 
> > Was that an ack?
> > 
> > I'm still sitting on Mikulas's "mm: allow __GFP_RETRY_MAYFAIL in
> > vmalloc", which has
> > 
> > 	Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
> > 	Acked-by: SeongJae Park <sj@kernel.org>
> > 	Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > 
> > I'm unsure how to proceed here?
> >
> IMO, we should drop the patch as it is not complete and replace it by the

Yes, that patch is not really correct as it allows to trigger OOM killer
during pte allocation.
 
> [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY
> 
> https://lore.kernel.org/lkml/20260302114740.2668450-2-urezki@gmail.com/

ack
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2026-03-11 12:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02 11:47 [PATCH] mm/vmalloc: Fix incorrect size reporting on allocation failure Uladzislau Rezki (Sony)
2026-03-02 11:47 ` [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY Uladzislau Rezki (Sony)
2026-03-02 17:38   ` Mikulas Patocka
2026-03-02 18:51     ` Michal Hocko
2026-03-10 22:59       ` Andrew Morton
2026-03-11  8:42         ` Uladzislau Rezki
2026-03-11 12:45           ` Michal Hocko [this message]
2026-03-11 18:21             ` Andrew Morton
2026-03-02 14:52 ` [PATCH] mm/vmalloc: Fix incorrect size reporting on allocation failure Dev Jain
2026-03-02 17:41 ` Mikulas Patocka
2026-03-03 20:04 ` Vishal Moola (Oracle)

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=abFj8gwNrpv0qQsJ@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpatocka@redhat.com \
    --cc=urezki@gmail.com \
    --cc=vishal.moola@gmail.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