From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (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 70E5F35DA55 for ; Fri, 24 Jul 2026 03:55:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784865355; cv=none; b=oAgMg2svuA+E4GYbWZh6JNLbnJVY5BtFsW4ItIKs/Pl5485eJ58ITihy6+wKjGL/vQO5vxic7ZK5S47sMJ3a/AFWoKYZsNgEdkmU4A5Avlzwv5lWyLnkR9wQpGDg2jIJlXU643XQKgLM/KFAPFFMNYJt/2iuGuP1xutFXaxQ8IM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784865355; c=relaxed/simple; bh=bY/WEK9yistReSta5XbgiXuBn1CFgZr4/J9CBfX8O9Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eiW5fkW8U+oC16K3KbTvt6LawqHS2qk+7uG0ojr2eWBLlD6R2jDRrrh7Df1I+mIVLraDUldbz16djZZ6CMzGaSlUgXoQfO4yu5/Y5G7zjUgH2Ca3HXEz7XUMAXdq+AYCOpLHnWXF2U834bCTI3wMsCkc2Xqu9eyzwkbE6Hrh85s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=TxvTHEFT; arc=none smtp.client-ip=209.85.222.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="TxvTHEFT" Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-930f618435cso135689185a.3 for ; Thu, 23 Jul 2026 20:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1784865352; x=1785470152; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=HNJfcC8jn5sdQ+MVI+mQj0PijBIpCe3BsXMVP5pD+So=; b=TxvTHEFTSPb6PFzdctuA3AIUO4n3oOxPakjyWcXxp2evIBuserE60WS4iDZkVf6mbr ek9Kgltwj7vrv41L0+gNvFnVRtj1Q32UL467lTUmu7eiu9BUBxA8E1CIvAAizXK1DBgd 24dLCxhOkmQwgdfP/DTRoh1nIc1RLvQ7RH231/Si7st0gkbgG3qlbAxZ20aKuzB7CrMO cvBQJTGAQzHTBDC32q8qnyMd5zK3AlxA5RuIlHXzTPShxKfV/6VtVFSocKtIO5Q9m1kJ Hxcq1sB9EUgeeyMLG+nrY41fcBnGuwi3FEAMv9HBBq0vT/B9TpJ9mSRvKJwCaHmSBWx0 Dceg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784865352; x=1785470152; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HNJfcC8jn5sdQ+MVI+mQj0PijBIpCe3BsXMVP5pD+So=; b=jLyo4VHaHoNrg+thw+mbKQtN5LhnjLL0EmY/3xa41YNRv3Qf29xtyvmD4luvsZUtoc Xok6YHuepbD2UoZTG+rN3yJFkaXQAjTqE8Ha5EVVKoxAbe1Q/W1GH0cpwl+LgcAR6tsc WOoZB2nxlk1hPH1k2kFEg33ME0fEMgYsQWOtayU/Z7BiBPhdXx+UrxeWvMxzQkXj5cRu Wb1ug91+EaoqOQ2ZwfUDKuNv8ijeG8NTRRGfAoB0paDGIym71o9t6v6LiioyhfbR6TLY WfZw5XfH+7F/nc2i/zB3bokBr+5MbAwC/DdHduPamO/ucX7q7FxezDh1Vssw0LF3in33 R9iw== X-Forwarded-Encrypted: i=1; AHgh+RpwAIBbyAWFng6qawv5tMmPIzzIVXiOwOZHydqijiPkl0OPR57r2aPTBQN5nmk12sHYRrdYt28qRfiIS88=@vger.kernel.org X-Gm-Message-State: AOJu0YxC3c22qd+Ut4SNj/Nwdu6BwMzDtKFINqG787fBXRRZ8Ns+Ltu6 TGQEixh3R49oAKG8Xe51ySTjEKiTWwjURp0EST+urGJ1SUq9vG1B47BnSHVe94r0w3M= X-Gm-Gg: AR+sD10+aiT1RyvAX7wnsTtt0LeyiBTNCCuXABe6nqQHmn33kUvXls1hBay0qyVOwNk YxEvGfz092QLRf172UH+kLQ78QqaUyF7mxOPi8iHLTyIKo1oGIi7RD1lxGiwg0Ni0bNSbcf1qWz 9HTUxdZLIiJw2f9RBgzzqRH+nuGuGTu5d1mSPpffl0iwz0y0vhjvJDCTie3viVuOy3kGCeDSjq/ S5yDORzFue9ogKRR99MRBqADVVWrmIIlpx6jxfAmXkcWFrwdYSgNQ5KBYv0fo+3Po0BW8n5s7s1 uSYcdzNMFj5MjyDDCB/bF6vJIbVAZLccHvyd6J4nTvqr6Eyd+xg+padcYzA4QJXcsJjyEk0/TrE TdA72ovwFpj3XSXu8a4n720cD0ZSEI1a/NqAwCvTdXMyHhSGwHb6xzsTH2zDlcr/A98o5SRLkQN kYQ+YgLTX2pG4kjB/d3BWQ1v30nIQb//Cxd3lDmhU2MaXx41q0UdyVEYufa9leEXM85pX+ X-Received: by 2002:a05:620a:4509:b0:931:7b8:eb8a with SMTP id af79cd13be357-93107b8ec3amr455545085a.15.1784865352170; Thu, 23 Jul 2026 20:55:52 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id af79cd13be357-930f687466esm570122185a.4.2026.07.23.20.55.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 20:55:51 -0700 (PDT) Date: Thu, 23 Jul 2026 23:55:46 -0400 From: Gregory Price To: Andrew Morton Cc: Johannes Weiner , Sean Christopherson , 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 Subject: Re: [PATCH] mm: mempolicy: fix automatic numa balancing for shmem Message-ID: References: <20260629163337.1264881-1-hannes@cmpxchg.org> <20260723171515.b5ddbc59c5c36ad01ef8f7fb@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260723171515.b5ddbc59c5c36ad01ef8f7fb@linux-foundation.org> 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. ~Gregory