The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Brendan Jackman" <brendan.jackman@linux.dev>
To: "Harry Yoo" <harry@kernel.org>,
	"Brendan Jackman" <jackmanb@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Michal Hocko" <mhocko@suse.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>, "Zi Yan" <ziy@nvidia.com>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Oscar Salvador" <osalvador@suse.de>,
	"David Hildenbrand" <david@kernel.org>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Joshua Hahn" <joshua.hahnjy@gmail.com>,
	"Rakie Kim" <rakie.kim@sk.com>,
	"Byungchul Park" <byungchul@sk.com>,
	"Ying Huang" <ying.huang@linux.alibaba.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Hao Li" <hao.li@linux.dev>, "Christoph Lameter" <cl@gentwo.org>,
	"David Rientjes" <rientjes@google.com>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Clark Williams" <clrkwllms@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>
Cc: "Gregory Price" <gourry@gourry.net>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Hao Ge" <hao.ge@linux.dev>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <linux-rt-devel@lists.linux.dev>
Subject: Re: [PATCH v3 05/16] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()
Date: Tue, 30 Jun 2026 17:04:21 +0000	[thread overview]
Message-ID: <DJMJPA37E3V0.39XKKI63O2ETU@linux.dev> (raw)
In-Reply-To: <397859cb-b127-4cc6-9c71-044afc99bf0c@kernel.org>

On Tue Jun 30, 2026 at 1:36 PM UTC, Harry Yoo wrote:
>> Ulterior motive: adding an alloc_flags arg to the allocator's
>> mm-internal entrypoint can later be used to do more allocation
>> customisation without needing to create new GFP flags.
>> 
>> While adding this flag to a bunch of places, create ALLOC_DEFAULT to
>> avoid a mysterious literal 0 in most places.
>>
>> alloc_frozen_pages_noprof() is defined above the alloc flags
>
> The function is defined below the alloc flags, no?

Yep this paragraph is stale since I created mm/page_alloc.h, will remove
it.

>> so just leave that as a slightly messy
>> exception instead of trying to fully reorder mm/internal.h for that one
>> case.
>> 
>> No functional change intended.
>> 
>> Signed-off-by: Brendan Jackman <jackmanb@google.com>
>> ---
>>  mm/hugetlb.c    |   3 +-
>>  mm/mempolicy.c  |  10 ++--
>>  mm/page_alloc.c | 178 +++++++++++++++++++++++++++++---------------------------
>>  mm/page_alloc.h |   6 +-
>>  mm/slub.c       |   6 +-
>>  5 files changed, 108 insertions(+), 95 deletions(-)
>> 
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index a3ba63c7f9199..8d409d075e3e9 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5271,24 +5271,98 @@ void free_pages_bulk(struct page **page_array, unsigned long nr_pages)
>>  	}
>>  }
>>  
>> +static inline bool alloc_trylock_allowed(void)
>> +{
>> +	/*
>> +	 * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is
>> +	 * unsafe in NMI. If spin_trylock() is called from hard IRQ the current
>> +	 * task may be waiting for one rt_spin_lock, but rt_spin_trylock() will
>> +	 * mark the task as the owner of another rt_spin_lock which will
>> +	 * confuse PI logic, so return immediately if called from hard IRQ or
>> +	 * NMI.
>> +	 *
>> +	 * Note, irqs_disabled() case is ok. This function can be called
>> +	 * from raw_spin_lock_irqsave region.
>> +	 */
>> +	if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
>> +		return false;
>> +
>> +	/* On UP, spin_trylock() always succeeds even when it is locked */
>> +	if (!IS_ENABLED(CONFIG_SMP) && in_nmi())
>> +		return false;
>
> Except for deferred_pages_enabled(), it's not specific to the page
> allocator. SLUB has
>
> 	/*
> 	 * See the comment for the same check in
> 	 * alloc_frozen_pages_nolock_noprof()
> 	 */
>
> ... and repeats the same thing as above.
>
> Perhaps let's factor it out into a helper
> rather than trying not to forget to update the other place?

Hm, not sure about this. I think I would say it's a "coincidence" that
these two bits of code look the same? Like, page_alloc.c uses
spin_trylock() so you can't do alloc_pages_nolock() from IRQ on
PREEMPT_RT. slub.c ALSO uses spin_trylock(), so you ALSO can't use
kmalloc_nolock() in those scenarios. But those are two different facts
that just happen to be isomorphic? Putting them into a shared helper
would kinda imply that these are part of a single system with inherently
coupled constraints.

I dunno I'm being a bit of a ponderous philosopher there, I don't have
particularly strong feelings. But I'd lean towards leaving this out of
the patchset since the potential deduplication isn't really related to
the other cleanups anyway.

  parent reply	other threads:[~2026-06-30 17:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260629-alloc-trylock-v3-0-57bef0eadbc2@google.com>
2026-06-29 14:00 ` [PATCH v3 00/16] mm: Some cleanups for page allocator APIs Mike Rapoport
2026-06-29 14:30   ` Brendan Jackman
2026-06-29 15:05     ` Brendan Jackman
     [not found] ` <20260629-alloc-trylock-v3-13-57bef0eadbc2@google.com>
2026-06-29 15:27   ` [PATCH v3 13/16] mm: Remove __alloc_pages_node() sashiko-bot
     [not found] ` <20260629-alloc-trylock-v3-9-57bef0eadbc2@google.com>
2026-06-29 15:31   ` -EXT-[PATCH v3 09/16] KVM: VMX: Use higher-level allocator API Soderlund, David
     [not found] ` <20260629-alloc-trylock-v3-16-57bef0eadbc2@google.com>
2026-06-29 16:02   ` [PATCH v3 16/16] mm: remove the __GFP_NO_OBJ_EXT flag sashiko-bot
2026-06-30 10:04     ` Brendan Jackman
     [not found] ` <20260629-alloc-trylock-v3-11-57bef0eadbc2@google.com>
2026-06-29 15:04   ` [PATCH v3 11/16] sgi-xp: Use higher-level allocator API sashiko-bot
2026-06-29 18:47   ` Steve Wahl
     [not found] ` <20260629-alloc-trylock-v3-15-57bef0eadbc2@google.com>
2026-06-29 15:56   ` [PATCH v3 15/16] mm: replace __GFP_NO_CODETAG with ALLOC_NO_CODETAG sashiko-bot
2026-06-30  4:34     ` Hao Ge
2026-06-30  1:55   ` Hao Ge
2026-06-30 10:10     ` Brendan Jackman
2026-06-30 12:01     ` Brendan Jackman
     [not found] ` <20260629-alloc-trylock-v3-1-57bef0eadbc2@google.com>
2026-06-30 12:27   ` [PATCH v3 01/16] mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK Vlastimil Babka (SUSE)
     [not found] ` <20260629-alloc-trylock-v3-2-57bef0eadbc2@google.com>
2026-06-30 12:38   ` [PATCH v3 02/16] mm/page_alloc: some renames to clarify alloc_flags scopes Vlastimil Babka (SUSE)
2026-06-30 17:25     ` Brendan Jackman
     [not found] ` <20260629-alloc-trylock-v3-3-57bef0eadbc2@google.com>
2026-06-30 12:43   ` [PATCH v3 03/16] mm: name some args in a function declaration Vlastimil Babka (SUSE)
     [not found] ` <20260629-alloc-trylock-v3-5-57bef0eadbc2@google.com>
2026-06-29 14:29   ` [PATCH v3 05/16] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof() sashiko-bot
2026-06-29 15:27     ` Brendan Jackman
2026-06-30 13:36   ` Harry Yoo
2026-06-30 15:34     ` Vlastimil Babka (SUSE)
2026-06-30 16:56       ` Brendan Jackman
2026-06-30 17:04     ` Brendan Jackman [this message]
2026-06-30 16:16   ` Vlastimil Babka (SUSE)
2026-06-30 18:47     ` Brendan Jackman
     [not found] ` <20260629-alloc-trylock-v3-4-57bef0eadbc2@google.com>
2026-06-29 14:16   ` [PATCH v3 04/16] mm: Split out internal page_alloc.h sashiko-bot
2026-06-30 13:54   ` Vlastimil Babka (SUSE)
     [not found] ` <20260629-alloc-trylock-v3-6-57bef0eadbc2@google.com>
2026-06-30 13:52   ` [PATCH v3 06/16] mm/page_alloc: relax GFP WARN in nolock allocs Harry Yoo
2026-06-30 16:42   ` Vlastimil Babka (SUSE)
     [not found] ` <20260629-alloc-trylock-v3-7-57bef0eadbc2@google.com>
2026-06-30 16:42   ` [PATCH v3 07/16] mm: move some stuff to mm/page_alloc.h Vlastimil Babka (SUSE)

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=DJMJPA37E3V0.39XKKI63O2ETU@linux.dev \
    --to=brendan.jackman@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=ast@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=byungchul@sk.com \
    --cc=cl@gentwo.org \
    --cc=clrkwllms@kernel.org \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=hao.ge@linux.dev \
    --cc=hao.li@linux.dev \
    --cc=harry@kernel.org \
    --cc=jackmanb@google.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=ljs@kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=rakie.kim@sk.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=willy@infradead.org \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.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