From: Vlastimil Babka <vbabka@suse.cz>
To: "Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Harry Yoo <harry.yoo@oracle.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm, slab: support NUMA policy for large kmalloc
Date: Mon, 2 Jun 2025 10:24:15 +0200 [thread overview]
Message-ID: <ba288a84-a4c9-4bf2-a584-f8c5d05c1767@suse.cz> (raw)
In-Reply-To: <17a999f3-7e6b-17d4-2caf-4912221894ec@gentwo.org>
On 5/30/25 21:05, Christoph Lameter (Ampere) wrote:
> On Thu, 29 May 2025, Vlastimil Babka wrote:
>
>> On 5/29/25 16:57, Christoph Lameter (Ampere) wrote:
>> > On Thu, 29 May 2025, Vlastimil Babka wrote:
>> >
>> >> The slab allocator observes the task's numa policy in various places
>> >> such as allocating slab pages. Large kmalloc allocations currently do
>> >> not, which seems to be an unintended omission. It is simple to correct
>> >> that, so make ___kmalloc_large_node() behave the same way as
>> >> alloc_slab_page().
>> >
>> > Large kmalloc allocation lead to the use of the page allocator which
>> > implements the NUMA policies for the allocations.
>> >
>> > This patch is not necessary.
>>
>> I'm confused, as that's only true depending on which page allocator entry
>> point you use. AFAICS before this series, it's using
>> alloc_pages_node_noprof() which only does
>>
>>
>> if (nid == NUMA_NO_NODE)
>> nid = numa_mem_id();
>>
>> and no mempolicies.
>
> That is a bug.
>
>> I see this patch as analogical to your commit 1941b31482a6 ("Reenable NUMA
>> policy support in the slab allocator")
>>
>> Am I missing something?
>
> The page allocator has its own NUMA suport.
It has support for respecting a preferred node (or forced node with
__GFP_THISNODE), nodemask, cpusets.
Mempolicy support is arguably outside the page allocator itself -
alloc_pages_mpol() lives in mm/mempolicy.c. Although some generically
looking wrappers alloc_pages() lead to it, while others don't
(__alloc_pages()). It's a kinda mess.
> The patch to reenable NUMA support dealt with an issue within the
> allocator where the memory policies were ignored.
I'd agree in the sense the issue was within the slab allocator, calling the
non-mpol-aware page allocator entry, which was not intended.
> It seems that the error was repeated for large kmalloc allocations.
After some digging, seems you're right and the error was done in commit
c4cab557521a ("mm/slab_common: cleanup kmalloc_large()") in v6.1. I'll add a
Fixes: tag and reword changelog accordingly.
> Instead of respecting memory allocation policies the allocation is forced
> to be local to the node.
It's not forced, but preferred, unless kmalloc() caller itself passes
__GFP_THISNODE. The slab layer doesn't add it.
> The forcing to the node is possible with GFP_THISNODE. The default needs
> to be following memory policies.
>
next prev parent reply other threads:[~2025-06-02 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 8:56 [PATCH 0/2] frozen pages " Vlastimil Babka
2025-05-29 8:56 ` [PATCH 1/2] mm, slab: use " Vlastimil Babka
2025-05-29 15:46 ` Roman Gushchin
2025-05-30 16:59 ` Matthew Wilcox
2025-05-30 4:17 ` Harry Yoo
2025-05-29 8:56 ` [PATCH 2/2] mm, slab: support NUMA policy " Vlastimil Babka
2025-05-29 14:57 ` Christoph Lameter (Ampere)
2025-05-29 15:59 ` Vlastimil Babka
2025-05-30 19:05 ` Christoph Lameter (Ampere)
2025-06-02 8:24 ` Vlastimil Babka [this message]
2025-05-30 7:11 ` Harry Yoo
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=ba288a84-a4c9-4bf2-a584-f8c5d05c1767@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=harry.yoo@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=willy@infradead.org \
/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