From: Johannes Weiner <hannes@cmpxchg.org>
To: Gregory Price <gourry@gourry.net>
Cc: Sean Christopherson <seanjc@google.com>,
Yan Zhao <yan.y.zhao@intel.com>,
pbonzini@redhat.com, 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>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Neha Gholkar <nehagholkar@gmail.com>,
kvm@vger.kernel.org, rick.p.edgecombe@intel.com,
vishal.l.verma@intel.com
Subject: Re: [PATCH] mm: mempolicy: fix automatic numa balancing for shmem
Date: Thu, 23 Jul 2026 13:07:04 -0400 [thread overview]
Message-ID: <amJKOPczNMb96NJv@cmpxchg.org> (raw)
In-Reply-To: <amIxyy4Vg_TTE8Y4@gourry-fedora-PF4VCD3F>
On Thu, Jul 23, 2026 at 11:58:27AM -0400, Gregory Price wrote:
> On Thu, Jul 23, 2026 at 10:54:06AM -0400, Johannes Weiner wrote:
> > >
> > > My stance is that using NUMA balancing with KVM guests is a terrible idea, and
> > > that anyone that insists on using such a setup gets to suffer the consequences.
> >
> > I agree. Surely we cannot leave shmem balancing broken due to
> > that. It's also not clear to me how many people even enable numa
> > balancing.
> >
>
> I lean towards Johannes' stance here that consistency is better, and if
> KVM has a known-poor interaction with numa balancing, maybe KVM should
> simply set a default policy (when none are present) to avoid this.
>
> That said, this is painful because MPOL_F_MOF / MPOL_F_MORON are already
> a silently inherited policy on boot (added during init). This will be
> confusing for users.
>
> This is not documented anywhere. Maybe this change should come with a
> docs addition that says the default global policy is ACTUALLY:
>
> MPOL_LOCAL + (MPOL_F_MOF | MPOL_F_MORON)
>
> Instead of just MPOL_LOCAL and letting that silent implementation
> detail bite people.
Hm, where do you see "Instead of just MPOL_LOCAL"?
Documentation/filesystems/tmpfs.rst says it defaults to "default" and
points me to set_mempolicy(2). That in turn in general makes little
mention of numa balancing and doesn't mention MPOL_F_MOF/MPOL_F_MORON.
In fact these are documented as internal flags.
The numa_balancing entry in
Documentation/admin-guide/sysctl/kernel.rst however DOES say plainly
that enabling this feature will sample and migrate mapped process
memory to where it's used, and that this has a performance penalty.
It seems there is a general lack of documented interactions between
user-requested policies and the system-wide numa-balancing behavior.
next prev parent reply other threads:[~2026-07-23 17:07 UTC|newest]
Thread overview: 22+ 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
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
2026-07-23 5:39 ` Yan Zhao
2026-07-23 13:51 ` Sean Christopherson
2026-07-23 14:54 ` Johannes Weiner
2026-07-23 15:58 ` Gregory Price
2026-07-23 17:07 ` Johannes Weiner [this message]
2026-07-23 17:48 ` Gregory Price
2026-07-23 18:45 ` Gregory Price
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=amJKOPczNMb96NJv@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=nehagholkar@gmail.com \
--cc=pbonzini@redhat.com \
--cc=rakie.kim@sk.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=vishal.l.verma@intel.com \
--cc=yan.y.zhao@intel.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.