linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
	"Uladzislau Rezki (Sony)" <urezki@gmail.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: Tue, 10 Mar 2026 15:59:14 -0700	[thread overview]
Message-ID: <20260310155914.9c03a9f4cc2f433fc741e222@linux-foundation.org> (raw)
In-Reply-To: <aaXcLRdhq0IyoNIG@tiehlicka>

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?


  reply	other threads:[~2026-03-10 22:59 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 [this message]
2026-03-11  8:42         ` Uladzislau Rezki
2026-03-11 12:45           ` Michal Hocko
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=20260310155914.9c03a9f4cc2f433fc741e222@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --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