From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 572083E314A for ; Mon, 27 Jul 2026 16:37:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785170276; cv=none; b=uilzfJaZPlg4skhcR1ozl9+2/kPe48CEiq6xQ2F4ny45a+/cpNtQXMuHCQAfgswh4nEvgEP6TXCdneuBIXTDFP9p0y1mXmlJmdbQZY5kkIyMq2bBlc/hcJW9KDYlNMCwRC66wmjngcthf4JH2q+GKi+A4J7jScbHZeE5lcPTOq0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785170276; c=relaxed/simple; bh=za25P21iRerR09HfB2lJ8DezWvhWIzLAuvQFIPRWmI8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CV3mPbj9W6MrB0+MhGKb+RRZsp1LEhIzn19qbPwLtwg+YmQOH7x4E9ZvxMalocD1hd2xpius/7IfAbRoOu9bOPf1/3gFuvU//0N1SwMas0EoHuqRRhiu7GEID5JhaaJmTe2STPvkU1yuKoPAVQP3S/apFEnH4REFZaFXy9fIwY4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=vt+PQuXG; arc=none smtp.client-ip=209.85.210.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vt+PQuXG" Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-8486ffba174so4708482b3a.1 for ; Mon, 27 Jul 2026 09:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785170267; x=1785775067; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=OOLQnJ1N4T9NlMm3RNk8fL/QgxOWSeQeUY1L1gTRIqQ=; b=vt+PQuXG5hSKGFJABnir7n06t/WiRPSu54KTwx1mMlAvXlkdZqCOwKaS1yCfSyY7k3 c+5Hoz3Er+HzwwwpcmMk9AxPgQRhurDaGn0ElFi4edcvtCyvL5y9zclzlEVy7mtYUeKC ORJTCvUf7kT4zLZ009c05kcLTltMdkC1NS+TTF/FAMEv3vBJB7CIe1Z+kuXmeBye89NT 4SJZw0+yB/5+tsSvFjehHy6Db7Oy3zeqpm01P5219s0Nh3LSgGJ9g3fUe+4nLFKAkLo8 ivO0gKPz9Brn8WnOQrUOenYO9aCVvHs1ABgPO+xHNz4tGHpcr8S4Atykp5POzEnwk5Mp o4Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785170267; x=1785775067; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=OOLQnJ1N4T9NlMm3RNk8fL/QgxOWSeQeUY1L1gTRIqQ=; b=OHv3goHpcVo5mBHhAjBz5gldw/WZ9ptWj6zrBTTprnVXkYAKwjG+PkKdZuq0cBPVSq SDgRsqq6R1rSbSVpGlDHnaOYoAnGcDyoKbfwlZerwehzwkaKhvSDGTpPDUOQsWO28HoJ ifx6F75rucGqGYwIfzS0nz7UHaLnb5GyDozvuEmTZNUomtLU2gn1/iBS5bscyTyy5blH Ws/ErqVOlCd6ym3IiXvANaQPehQZIM4k8yBhOl05AaACsQxioQvfYzL4z3MDwc5CA5DM EHyOz847aGF2rDLj3gRfUnRK+44bARoE3a1k21A9tz4GYJ7YIsN29/nezez7wkPYnThW qxnA== X-Forwarded-Encrypted: i=1; AHgh+RpeKJ/6v6HWo1fsqsbMRXtlfCom7PDQIu7n76/NGgDdZJ+6tt0LNGbGy9rZSgR0GQ82JhFetHonb8eVH1k=@vger.kernel.org X-Gm-Message-State: AOJu0YxMS8fblUgORsy1cZw2aUyML5Q4WBqhAkzeAn8JyOLGVQ7NTSrW cMcYfkykx0icQxiq77BZjKde+ChfwAl2W7B6jlgsItHha9YHQ22g2IIxQ1+3fg4rvrvkSwKkzwF zR5qegw== X-Received: from pfwy37.prod.google.com ([2002:a05:6a00:1ca5:b0:848:7f21:167c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2393:b0:846:2f3c:3f68 with SMTP id d2e1a72fcca58-84e8d0a7c58mr137097b3a.57.1785170266555; Mon, 27 Jul 2026 09:37:46 -0700 (PDT) Date: Mon, 27 Jul 2026 09:37:45 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260629163337.1264881-1-hannes@cmpxchg.org> <20260723171515.b5ddbc59c5c36ad01ef8f7fb@linux-foundation.org> Message-ID: Subject: Re: [PATCH] mm: mempolicy: fix automatic numa balancing for shmem From: Sean Christopherson To: Gregory Price Cc: Andrew Morton , Johannes Weiner , Yan Zhao , pbonzini@redhat.com, David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Neha Gholkar , kvm@vger.kernel.org, rick.p.edgecombe@intel.com, vishal.l.verma@intel.com Content-Type: text/plain; charset="us-ascii" 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 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.