From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (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 14FCF42AFB1 for ; Thu, 23 Jul 2026 15:58:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784822318; cv=none; b=V5+ZBPiAAiJSyPmQyszyk/SyOLpZFJFeiQoScSN2Rs/YdJ87ZUgRN6KsAgkR+m1s0nhaZSMXwdWTKgfmGHjlt13RPuYTI5i+GqbweLICXn2gnLGwivGDXEhc2GbdJYcv3NnFaOfaFYo2n1b9dDGOKRHhCRikY/4wSuWQ3pX9L1U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784822318; c=relaxed/simple; bh=qlxjHxg0aKO43aQp28f/OFH/keg5U1hhwcde6rqWGEg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YfC0TNz8MbWndKZYTiJyw8LTaLv/euHhuUeuSR0kXdRgnXVOrqd8kzlWKJ54AgI67MUH7hA395LQxCavbSvnrI+D1fjEp7jGNz6dFpXZoHnS4VaYZe/Zhdbzqsa61D89DG9jF3QgxgDRHlmTKsSDAfD9K3Q595cm94lz3jxi38s= 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=Cgs+a2F8; arc=none smtp.client-ip=209.85.222.171 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="Cgs+a2F8" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-92f0b5ed131so77832885a.3 for ; Thu, 23 Jul 2026 08:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1784822314; x=1785427114; 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=g76/VCTunnMtb1dTlZWxSdXy3jUc5pTpstI44HSyfHw=; b=Cgs+a2F8/dI1G05i6c49L6Zm+g/D4YnuzywoDSi98wX7hTxubqn4qNkTDTYJ2k7igO HI25kUaXiFyZf0T1wMK4W6girHDUAUCo9mNE//esq2Gszt8/JR9+B7h9iHOxuTx6bQBN Ku8JIfr8R9/FbMsfe4fTtO4Qmxb6J8sP3s9E4VsOAFC2pUygFIkhBq3zuBWbSFggi8jG 7LX9+dYzEVJL4kdFoDIqP1JdmUoqX5SbuUx7AMT0K+fm6J1mv/eGBDCa2xuicEgZs214 l/bGuCqW3F6cZhHe691sFl/8GB3+Ra2ooI7J7ffNob1EeOEYqjY/J8pMV4zI44fJtbFF 1GWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784822314; x=1785427114; 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=g76/VCTunnMtb1dTlZWxSdXy3jUc5pTpstI44HSyfHw=; b=ZslgMQPkQMPxiqqRWn6uuSv7M0Gxwm+vnGYFajd7qTo8EmKMUAfc0a7zLiFp/8ARAZ 9RPGtL7Lc9SQKnzvvm842ZYrTPHFD4hB6nIi01rLo8PWr5NbFNnhng59viNLnKlsPESt ke5xkffyvoOPy6mfQpSFRf6x60NzveBCwabU98t7Y16aqbFJ5WZj5DmGpGEE+Ru8BnsY V1vLjqfnzcaLxGjRrV6uuwfBLmE14s7oJbQa+KnxgnuyNVZTnmipto+mEpP6GxDtZnj6 ErpybMOkAG1NW37XiTG2RJLCE5i1PxbXlbcZ1SXvgHooSUYQMG4QTp6gi8w4XuLY+QZP lltg== X-Forwarded-Encrypted: i=1; AHgh+RoyZkEAEyw3OXI+YyYsDZGnwGSD5gM/cM2z//rmbhzT62SrH4uFf5UG66FWwgu3gN9XsTFi+XGMbgwLuHA=@vger.kernel.org X-Gm-Message-State: AOJu0YzFBdSo/GO93ijj7c7ejXc2cCOhK9YmcKe2JRbzObl+ccAwL16M m6pS3WTTYOmddr6SQQ/eHXE1Jb7akBdzZdzm6BwVmfGhph9YcUPmWifsxO+CfaWFy+E= X-Gm-Gg: AR+sD12t5DesXSs0K5ge/DBuSTsxUtb+r/v6ehW029L2BegtZc8tJT+4vuJbjDgE+dB 6HA7XsVj7f5t2U7pusoYSz+RkEXg8JGWrE/RcFRCK9VK68FA4k54SyUMnbHHPXUXeZ74gNNIkCZ g+yAstrQsY2Uzkh51PIjXrUEuEgvooIIkOPFCq+eeJvCM1rIOWP9CWMtnPvE5Cn2uVu79mm2/e3 Z1Y70OoFaJq2MO9IdDzjljLvGA7TbXDv3mZuyzHU/t0uemUpIlClzH16nvXvGNZYA4O48j3Qh0l UygS+Z9nbiEQPjDW85+LvrdUHqJmUXYq7gz2ASI0CleA16md3T7LboHhlz5tZaZggXypc4+mI8c HMo2ewO/TATFAchyT9bhC9Jfo5eDsxecV7FVrfq3dlmpzg6PaoRk6yl++03naoAn3PO7lqZEU1D fwqUyu55jdT1KkFguflLGYf75IrGBcCTpoLGbbuK6/EgDMFaZ/NcKW5oHn3Q== X-Received: by 2002:a05:620a:1726:b0:92e:7d7a:108b with SMTP id af79cd13be357-93103aee60bmr357433185a.50.1784822314110; Thu, 23 Jul 2026 08:58:34 -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-930f6a03834sm441323085a.30.2026.07.23.08.58.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 08:58:33 -0700 (PDT) Date: Thu, 23 Jul 2026 11:58:27 -0400 From: Gregory Price To: Johannes Weiner Cc: Sean Christopherson , Yan Zhao , pbonzini@redhat.com, Andrew Morton , 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> 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: 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. ~Gregory