All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Brendan Jackman" <brendan.jackman@linux.dev>
To: "Hao Ge" <hao.ge@linux.dev>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Brendan Jackman" <brendan.jackman@linux.dev>
Cc: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
	"Brendan Jackman" <jackmanb@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"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>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Harry Yoo (Oracle)" <harry@kernel.org>,
	"Gregory Price" <gourry@gourry.net>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <linux-rt-devel@lists.linux.dev>
Subject: Re: [PATCH] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()
Date: Mon, 22 Jun 2026 08:33:12 +0000	[thread overview]
Message-ID: <DJFFTJZGYZ91.6Y7J8M13KU5@linux.dev> (raw)
In-Reply-To: <267e070f-adc2-4f42-b528-746f852d9ef4@linux.dev>

On Mon Jun 22, 2026 at 1:58 AM UTC, Hao Ge wrote:
>
> On 2026/6/20 02:08, Suren Baghdasaryan wrote:
>> On Fri, Jun 19, 2026 at 4:57 AM Brendan Jackman
>> <brendan.jackman@linux.dev> wrote:
>>> On Thu Jun 18, 2026 at 2:22 AM UTC, Hao Ge wrote:
>>>> On 2026/6/18 01:14, Brendan Jackman wrote:
>>>>> On Wed Jun 17, 2026 at 4:49 PM UTC, Suren Baghdasaryan wrote:
>>>>>> On Wed, Jun 17, 2026 at 9:39 AM Vlastimil Babka (SUSE)
>>>>>> <vbabka@kernel.org> wrote:
>>>>>>> +Cc Alexei
>>>>>>>
>>>>>>> On 6/17/26 17:29, Brendan Jackman wrote:
>>>>>>>> Currently the core allocator code is controlled by ALLOC_NOLOCK, but the
>>>>>>> It's not, it's ALLOC_TRYLOCK! Thanks for proving that we need to rename it
>>>>>>> to ALLOC_NOLOCK:
>>>>>>>
>>>>>>> https://lore.kernel.org/all/DJ9QPTO2WXNB.10E88ZHWRDHB0@gmail.com/
>>>>>>>
>>>>>>> So you just won the job to do the rename :) I think it should be done before
>>>>>>> this patch, so that the new usages and other _trylock names introduced here
>>>>>>> can be done as _nolock outright.
>>>>> Ack. I'll aim to send that tomorrow once Sashiko has caught up.
>>>>>
>>>>>>>> main entry point function is significantly different from the normal
>>>>>>>> __alloc_frozen_pages_nolock(), this is tiring when reading the code.
>>>>>>>>
>>>>>>>> Plumb the ALLOC_NOLOCK control one layer up in the call stack: create
>>>>>>>> an alloc_flags argument to __alloc_frozen_pages_nolock() (which is only
>>>>>>>> exposed to mm/) and then turn the nolock variant into a thin wrapper
>>>>>>>> that just sets that flag (as well as handling NUMA_NO_NODE, similar to
>>>>>>>> how some of the wrappers in gfp.h do).
>>>>>>>>
>>>>>>>> Rationale that this doesn't change anything:
>>>>>>>>
>>>>>>>> 1. Simple bits: A bunch of the nolock-specific handling is just moved to
>>>>>>>>      the new alloc_order_allowed(), alloc_trylock_allowed() and
>>>>>>>>      gfp_trylock.
>>>>>>>>
>>>>>>>> 2. __alloc_frozen_pages_noprof() has some extra logic that wasn't
>>>>>>>>      previously in the nolock variant:
>>>>>>>>
>>>>>>>>      a. Application of gfp_allowed_mask; this only affects early boot, and
>>>>>>>>         only flags that affect the slowpath get changed here.
>>>>>>>>
>>>>>>>>      b. Application of current_gfp_context() - also only affects the
>>>>>>>>         slowpath
>>>>>>>>
>>>>>>>> 3. The slowpath itself: this is now just explicitly skipped under
>>>>>>>>      !ALLOC_TRYLOCK.
>>>>>>> I'll have to ponder it more closely.
>>>>>>>
>>>>>>>> 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.
>>>>>>> Ack.
>>>>>> I think this change might also help us in removing __GFP_NO_CODETAG
>>>>> Nice, this actually looks trivial? I can probably just tack it onto the
>>>>> v2 for this patch/series.
>>>>>
>>>>>> introduced in [1] and being the only user of __GFP_NO_OBJ_EXT once
>>>>>> Vlastimil's patchset removing other __GFP_NO_OBJ_EXT users lands.
>>>>>> CC'ing Hao as he is brainstorming ways to remove __GFP_NO_CODETAG, and
>>>>>> this might be the answer.
>>>>
>>>> Hi Brendan, Suren,
>>>>
>>>> Thanks for CC'ing me, Suren. This is indeed a viable approach
>>>>
>>>> and I believe it brings us one step closer to removing
>>>>
>>>> __GFP_NO_CODETAG entirely.
>>>>
>>>>
>>>> Brendan, I'd actually put together a rough local implementation
>>>>
>>>> earlier with mostly the same core idea as yours, and this change
>>>>
>>>> would indeed be minimal based on your patch.
>>>>
>>>> Thanks a lot for being interested in tacking this into your v2 patch series.
>>> Oh, I just took a look and it's a bit more fiddly than I thought because
>>> alloc_tag.c is actually in lib/ not mm/.
>
> Hi Suren and Bredan
>
>
>> One option is to move alloc_tag.c into mm/ (while keeping more generic
>> codetag.c in lib/). From a quick look, that seems doable and probably
>> the easiest approach.
>>
>>> How did you tackle that, can you share your implementation? It would be
>>> nice if we can avoid exposing alloc_flags in gfp.h.
>
> First, I introduced the ALLOC_NO_CODETAG flag as shown below:
>
> @@ -1478,6 +1480,7 @@ unsigned int reclaim_clean_pages_from_list(struct 
> zone *zone,
>   #define ALLOC_HIGHATOMIC       0x200 /* Allows access to 
> MIGRATE_HIGHATOMIC */
>   #define ALLOC_TRYLOCK          0x400 /* Only use spin_trylock in 
> allocation path */
>   #define ALLOC_KSWAPD           0x800 /* allow waking of kswapd, 
> __GFP_KSWAPD_RECLAIM set */
> +#define ALLOC_NO_CODETAG       0x1000 /* skip codetag tracking for this 
> allocation */
>
>
> Then, mirroring __alloc_pages_noprof, we wrapped a helper function named 
> alloc_pages_noprof_notag.
>
>
> @@ -5252,13 +5335,25 @@ struct page *__alloc_pages_noprof(gfp_t gfp, 
> unsigned int order,
>   {
>          struct page *page;
>
> -       page = __alloc_frozen_pages_noprof(gfp, order, preferred_nid, 
> nodemask);
> +       page = __alloc_frozen_pages_noprof(gfp, order, preferred_nid, 
> nodemask, 0);
>          if (page)
>                  set_page_refcounted(page);
>          return page;
>   }
>   EXPORT_SYMBOL(__alloc_pages_noprof);
>
> +struct page *alloc_pages_noprof_notag(gfp_t gfp, unsigned int order)
> +{
> +       struct page *page;
> +
> +       page = __alloc_frozen_pages_noprof(gfp, order, numa_node_id(), NULL,
> +                                          ALLOC_NO_CODETAG);
> +       if (page)
> +               set_page_refcounted(page);
> +       return page;
> +}
> +EXPORT_SYMBOL_GPL(alloc_pages_noprof_notag);
>
>
> Lastly, we exported this function in gfp.h as shown below:
>
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 51ef13ed756e..ac6e837ac8c0 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -234,6 +234,9 @@ struct folio *__folio_alloc_noprof(gfp_t gfp, 
> unsigned int order, int preferred_
>                  nodemask_t *nodemask);
>   #define __folio_alloc(...) alloc_hooks(__folio_alloc_noprof(__VA_ARGS__))
>
> +struct page *alloc_pages_noprof_notag(gfp_t gfp, unsigned int order);
> +#define alloc_pages_notag(...) 
> alloc_hooks(alloc_pages_noprof_notag(__VA_ARGS__))
>
>
> Hope this information helps you.

Cool, thanks! On Friday I also tried doing it by just moving the .c
file and that also seems to be pretty practical. 

  reply	other threads:[~2026-06-22  8:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 15:29 [PATCH] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof() Brendan Jackman
2026-06-17 16:39 ` Vlastimil Babka (SUSE)
2026-06-17 16:49   ` Suren Baghdasaryan
2026-06-17 17:14     ` Brendan Jackman
2026-06-18  2:22       ` Hao Ge
2026-06-19 11:57         ` Brendan Jackman
2026-06-19 18:08           ` Suren Baghdasaryan
2026-06-22  1:58             ` Hao Ge
2026-06-22  8:33               ` Brendan Jackman [this message]
2026-06-18  6:56 ` Hao Ge
2026-06-19  8:03   ` Brendan Jackman
2026-06-19  3:56 ` Matthew Wilcox
2026-06-19  8:17   ` Brendan Jackman
2026-06-19  8:43     ` Brendan Jackman
2026-06-22  8:24     ` 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=DJFFTJZGYZ91.6Y7J8M13KU5@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=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 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.