From: "JP Kobryn (Meta)" <jp.kobryn@linux.dev>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@suse.com
Cc: apopple@nvidia.com, axelrasmussen@google.com, byungchul@sk.com,
cgroups@vger.kernel.org, david@kernel.org, eperezma@redhat.com,
gourry@gourry.net, jasowang@redhat.com, hannes@cmpxchg.org,
joshua.hahnjy@gmail.com, Liam.Howlett@oracle.com,
linux-kernel@vger.kernel.org, lorenzo.stoakes@oracle.com,
matthew.brost@intel.com, mst@redhat.com, rppt@kernel.org,
muchun.song@linux.dev, zhengqi.arch@bytedance.com,
rakie.kim@sk.com, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, surenb@google.com,
virtualization@lists.linux.dev, weixugc@google.com,
xuanzhuo@linux.alibaba.com, ying.huang@linux.alibaba.com,
yuanchu@google.com, ziy@nvidia.com, kernel-team@meta.com
Subject: Re: [PATCH v2] mm/mempolicy: track page allocations per mempolicy
Date: Thu, 12 Mar 2026 09:13:49 -0700 [thread overview]
Message-ID: <343bbd5b-67a0-46c4-8ec4-69158bf26b3f@linux.dev> (raw)
In-Reply-To: <3a42463b-9ddd-4d64-b64c-6c2e6e4fc75d@kernel.org>
On 3/12/26 6:40 AM, Vlastimil Babka (SUSE) wrote:
> On 3/7/26 05:55, JP Kobryn (Meta) wrote:
>> When investigating pressure on a NUMA node, there is no straightforward way
>> to determine which policies are driving allocations to it.
>>
>> Add per-policy page allocation counters as new node stat items. These
>> counters track allocations to nodes and also whether the allocations were
>> intentional or fallbacks.
>>
>> The new stats follow the existing numa hit/miss/foreign style and have the
>> following meanings:
>>
>> hit
>> - for BIND and PREFERRED_MANY, allocation succeeded on node in nodemask
>> - for other policies, allocation succeeded on intended node
>> - counted on the node of the allocation
>> miss
>> - allocation intended for other node, but happened on this one
>> - counted on other node
>> foreign
>> - allocation intended on this node, but happened on other node
>> - counted on this node
>>
>> Counters are exposed per-memcg, per-node in memory.numa_stat and globally
>> in /proc/vmstat.
>>
>> Signed-off-by: JP Kobryn (Meta) <jp.kobryn@linux.dev>
>
> I think I've been on of the folks on previous versions arguing against the
> many counters, and one of the arguments was it they can't tell the full
> story anyway (compared to e.g. tracing), but I don't think adding even more
> counters is the right solution. Seems like a number of other people
> responding to the thread are providing similar feedback.
>
> For example I'm still not sure how it would help me if I knew the
> hits/misses were due to a preferred vs preferred_many policy, or interleave
> vs weithed interleave?
>
How about I change from per-policy hit/miss/foreign triplets to a single
aggregated policy triplet (i.e. just 3 new counters which account for
all policies)? They would follow the same hit/miss/foreign semantics
already proposed (visible in quoted text above). This would still
provide the otherwise missing signal of whether policy-driven
allocations to a node are intentional or fallback.
Note that I am also planning on moving the stats off of the memcg so the
3 new counters will be global per-node in response to similar feedback.
next prev parent reply other threads:[~2026-03-12 16:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 4:55 [PATCH v2] mm/mempolicy: track page allocations per mempolicy JP Kobryn (Meta)
2026-03-07 12:27 ` Huang, Ying
2026-03-08 19:20 ` Gregory Price
2026-03-09 4:11 ` JP Kobryn (Meta)
2026-03-09 4:31 ` JP Kobryn (Meta)
2026-03-11 2:56 ` Huang, Ying
2026-03-11 17:31 ` JP Kobryn (Meta)
2026-03-07 14:32 ` kernel test robot
2026-03-07 19:57 ` kernel test robot
2026-03-08 19:24 ` Usama Arif
2026-03-09 3:30 ` JP Kobryn (Meta)
2026-03-11 18:06 ` Johannes Weiner
2026-03-09 23:35 ` Shakeel Butt
2026-03-09 23:43 ` Shakeel Butt
2026-03-10 4:17 ` JP Kobryn (Meta)
2026-03-10 14:53 ` Shakeel Butt
2026-03-10 17:01 ` JP Kobryn (Meta)
2026-03-12 13:40 ` Vlastimil Babka (SUSE)
2026-03-12 16:13 ` JP Kobryn (Meta) [this message]
2026-03-13 5:07 ` Huang, Ying
2026-03-13 6:14 ` JP Kobryn (Meta)
2026-03-13 7:34 ` Vlastimil Babka (SUSE)
2026-03-13 9:31 ` Huang, Ying
2026-03-13 18:28 ` JP Kobryn (Meta)
2026-03-13 18:09 ` JP Kobryn (Meta)
2026-03-16 2:54 ` Huang, Ying
2026-03-17 4:37 ` JP Kobryn (Meta)
2026-03-17 6:44 ` Huang, Ying
2026-03-17 11:10 ` Vlastimil Babka (SUSE)
2026-03-17 17:55 ` JP Kobryn (Meta)
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=343bbd5b-67a0-46c4-8ec4-69158bf26b3f@linux.dev \
--to=jp.kobryn@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=byungchul@sk.com \
--cc=cgroups@vger.kernel.org \
--cc=david@kernel.org \
--cc=eperezma@redhat.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jasowang@redhat.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=mst@redhat.com \
--cc=muchun.song@linux.dev \
--cc=rakie.kim@sk.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=weixugc@google.com \
--cc=xuanzhuo@linux.alibaba.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.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.