From: Gregory Price <gourry@gourry.net>
To: "Huang, Ying" <ying.huang@linux.alibaba.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Alistair Popple <apopple@nvidia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Neha Gholkar <nehagholkar@gmail.com>
Subject: Re: [PATCH] mm: mempolicy: fix automatic numa balancing for shmem
Date: Mon, 6 Jul 2026 13:30:08 -0400 [thread overview]
Message-ID: <akvmIILwRsU9mUfk@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <87y0fonyrm.fsf@DESKTOP-5N7EMDA>
On Mon, Jul 06, 2026 at 07:27:57PM +0800, Huang, Ying wrote:
> >
> > I considered proposing MPOL_F_MOVABLE_ONLY to mean (roughly) "userland
> > memory only" - and then slowly trying to migrate numactl to make this
> > the default.
>
> What is the right mempolicy for these random kernel allocations? If the
> pages are used privately by the task (not the case in your example, but
> is it possible?), is it OK to use the mempolicy of the task? If the
> pages are shared, what is the correct mempolicy? Will it be fixed? Or
> can we find a way to change the policy?
>
I submitted a recommendation[1], but I think it got swalled by the kvack
outage, i'll probably need to re-send.
At the very least, these allocations should just use the system default
(local node) instead of the task.
I left the page-cache affected by this (so inode data DOES follow this)
but after some testing I found this amounts to around ~0.4% of total
memory usage when you have many small files (~64kb files, 512GB cached).
I think we can probably drop the first commit and just ship the second.
The fun result - when you combine this fix + private nodes [2] you can
reliably hotplug a private node in ZONE_NORMAL so long as all tasks that
were using the private node were reaped prior to hotplug.
This is a legitimately useful improvement in my opinion.
~Gregory
[1] https://lore.kernel.org/all/20260701222112.2820098-1-gourry@gourry.net/
[2] https://lore.kernel.org/all/20260222084842.1824063-1-gourry@gourry.net/
next prev parent reply other threads:[~2026-07-06 17:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 16:33 [PATCH] mm: mempolicy: fix automatic numa balancing for shmem Johannes Weiner
2026-06-29 17:59 ` Gregory Price
2026-06-29 18:22 ` Johannes Weiner
2026-06-30 11:20 ` Huang, Ying
2026-06-30 15:29 ` Gregory Price
2026-07-01 11:03 ` Huang, Ying
2026-07-01 15:33 ` Gregory Price
2026-07-01 15:49 ` Johannes Weiner
2026-07-01 16:22 ` Gregory Price
2026-07-06 11:27 ` Huang, Ying
2026-07-06 17:30 ` Gregory Price [this message]
2026-06-29 18:33 ` David Hildenbrand (Arm)
2026-06-29 18:47 ` Johannes Weiner
2026-06-30 11:26 ` David Hildenbrand (Arm)
2026-06-30 23:40 ` Balbir Singh
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=akvmIILwRsU9mUfk@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=nehagholkar@gmail.com \
--cc=rakie.kim@sk.com \
--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.