The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Gregory Price <gourry@gourry.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	 Yan Zhao <yan.y.zhao@intel.com>,
	pbonzini@redhat.com,  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: Mon, 27 Jul 2026 09:37:45 -0700	[thread overview]
Message-ID: <ameJWWjYXuONB6VF@google.com> (raw)
In-Reply-To: <amLhu07IpWfBbWC0@gourry-fedora-PF4VCD3F>

On Thu, Jul 23, 2026, Gregory Price wrote:
> On Thu, Jul 23, 2026 at 05:15:15PM -0700, Andrew Morton wrote:
> > On Thu, 23 Jul 2026 10:54:06 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote:
> > 
> > > > But in this case, IIUC, this change will "silently" enable NUMA balancing for
> > > > shmem-based KVM setups where it was previously disabled (albeit unintentionally).
> > > > 
> > > > I'm not fundamentally opposed to the change, but I do worry that downstream KVM
> > > > users could be in for a nasty surprise.
> > 
> > It is a bit concerning.
> > 
> > > This should be very visible in early kernel validation after an
> > > upgrade. VM hosts tend to not do much else, with VM memory dominating
> > > the host. You'd expect a significant uptick in numa_pte_updates,
> > > numa_hint_faults, and a change in per-node nr_shmem stats. And the
> > > patch subject makes it trivial to find in a commit delta scan.
> > 
> > Is there anything we can do to make this process less painful? 
> > Documentation of course, but what about detecting the situation and
> > emitting a once-off warning?
> 
> Maybe a rate-limited or one-time pr_info/warn on the first PROT_NONE
> fault affecting KVM in the painful zap path?
> 
> Non-invasive, targeted, and helpful.

Unfortunately, keying off PROT_NONE probably isn't all that targeted and thus
may or may not be helpful, as it would generate what are effectively false
positives for setups where NUMA balacing is already fully enabled.  In my
experience, KVM users tend to freak out if there's a "scary" kernel message,
even if everything is working exactly how the admin intended.

Thinking about this more, I'm probably being overly paranoid.  The failing KVM
selftest is (very deliberately) about as pathologically stupid as things can get,
i.e. it's not representative of real-world setups.

How about we do nothing for now, and then revisit trying to find a useful way to
alert the end user *if* we start seeing KVM bug reports?  As you said earlier, I
think "You turned numa balancing on" is an acceptable answer at this time.  

      reply	other threads:[~2026-07-27 16:37 UTC|newest]

Thread overview: 27+ 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
2026-07-23 17:48           ` Gregory Price
2026-07-23 18:45             ` Gregory Price
2026-07-23 22:30               ` Yosry Ahmed
2026-07-23 22:56                 ` Gregory Price
2026-07-24  0:15       ` Andrew Morton
2026-07-24  3:55         ` Gregory Price
2026-07-27 16:37           ` Sean Christopherson [this message]

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=ameJWWjYXuONB6VF@google.com \
    --to=seanjc@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox