From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (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 A68BA2F8E93 for ; Mon, 29 Jun 2026 17:59:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782755988; cv=none; b=VNpgzI0hh6bI0gLrmlTs4+n++KLiVwcaGABCR3Dg4T0qqAFZJ1P4Y1Q25jnb1RLvx96PYK6XBv4ljVZoXlydK2FWTIO62vP9aM63sDe6wn3/ajOPsBw4HPScTgYi1W1n+8rKAzT4Hs2tsd2XhoTCttviYpH0AMH7dIJnLqaoOZY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782755988; c=relaxed/simple; bh=anaCqlPnmTiARN7uXvTINxrMj9gFWDDxQOvlclj7sGU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kdE5hqFSpzWtVPsjsqhLw7gUtnzvRBFb+nzmHkKF6iS8fUJBYIwTIF+CpMCKXYAXuAZaEi22T4eNeZwL7sHhoVTzKl/74MfHQlhgULJZMWiUeXN8b7reRR4ZMGPrWEaDqbPYlFyCyJnogiOm7h75y5iit7pLKSVRA1D+1JDu6I0= 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=cgGNcApv; arc=none smtp.client-ip=209.85.219.51 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="cgGNcApv" Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-8ef7b7651ecso17162136d6.1 for ; Mon, 29 Jun 2026 10:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1782755986; x=1783360786; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=h9Yhc8Z7dfCeWR08HYYvVeN4gNBQUwzZk9IGQ1OytMs=; b=cgGNcApvf0fqfxHxmfmYhHi6BK8xed8Hx6GxlMipW0CRM/VoIzifSNHqciMvmHHSve wRRSZoFq2xbun2yBHQ5zuO7C0gYhOomGU97WR63ZegpnlmxVSgYl/zJH2g4Evo8g8phS wqgp0X7xMJNOzbMmqVaIeKU3EtIdxIJ3CJwyMkgOap34uPVHbTv2M89hLKdWgGPjfBM0 Y1IrvIMt8aTOCyxQ2VE6HgRBZ1q95qqeQRux5wKAesa06miOP/9AibCxDzORVdjq9ZGo oYFuwZ96ywQbPF6U461eDizA8cpKCLYSI4OR3mgfDgAoZSZKlGf9AUKHF7/5PWENGxQi i8fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782755986; x=1783360786; h=in-reply-to:content-disposition: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; bh=h9Yhc8Z7dfCeWR08HYYvVeN4gNBQUwzZk9IGQ1OytMs=; b=rMhZEdMiI9014DOgeo047whR5ztuW2dUYeVMz+L3IwfvXF3k/j1vOlxkgUZIm7umJP vx0Ha/7ysXNWkL0IPiM1YkAqRL6ivD2GLpvKwZZETMTC5cmV4OtIKfRcLQytvimb3JU8 fKluGT7ZJvSJUkscbPTMRPka+CYhdStH1xNHYPVzoBA3x1/pFJRm74Qr8L41VYERglhn nUuhMAjT48NDkk5sbMaeNzysMGFnE75E0rrtMjLNAngqu9nMJsftzGmCks0FuGSxFcNb Pz/WOT42OdNsXrdhWbuDtpyCqCiiui5YKkDRzUY2uCHC1ynwOGq70LzsaPk6pnueVRhC UDMA== X-Forwarded-Encrypted: i=1; AFNElJ9t+JKRsDVZUTJNfUwGlYNbpCZFnHmwfrSYifqwmVFkOAESjCUkcp6eVGur3PtvAR7kCqd1WniAsGL0/EI=@vger.kernel.org X-Gm-Message-State: AOJu0YymWySbv3d7IMrEF6Jjb4lPfkxeZgjduLvoTEcfaQNRDQwmkB3t /JlBJmB9SpXXERxXZU6epe9Tdf/bxgQXMtzbtF8NF9gICkgbp+6lKtNVvJEZxY9c6ys= X-Gm-Gg: AfdE7cnMsY8GuufXWw0v5QiCduQpUAjeextAH4cuiMQ06Bfzl/ygiDUnsUTvZL0tfE9 mcsK03UGlEaKsli/qPukOr+pYM8m0/7uBBLLVlhENl0eEjVgy37BOg0mcaMdqAlQxmsExWy8Fza oC+GQzqUHgAD5aRO6Gzk5ec0Yk+IY/x/XLGp3BoEDheCV6KIW1NgOEGuuCcDNYlUPA8t2NsevoA 6uizITfbZ2adzZVEw+o6WHUFs4AdKr9j/QVnETmXiT+Yd0Eyyqh2u1RWTmSIrLHTHChw8mh22pi Hq73gCqfKu/uBjco0EeWbRQGCYwidzRSo4WtRQO54dX19U6aIh831uEa9udCyKE8zZdh6y43Y9L BgtirLNMHXy1Nw9X6GjbCN/OWIRTZCLTbiVAN6H6TekZEsHlwVYQRRNIVYHvUzECgV40/NbBCmT BFf1uZA8QRFfD53VgmQB9oq61aEJr0zVaQrX49CCogURkflb0I4LBjN4soHMkveSrvCdGN X-Received: by 2002:ac8:570d:0:b0:51a:8c86:bd2f with SMTP id d75a77b69052e-51c10e34decmr3389891cf.36.1782755985715; Mon, 29 Jun 2026 10:59:45 -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 d75a77b69052e-51c10a3307csm1345581cf.29.2026.06.29.10.59.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 10:59:45 -0700 (PDT) Date: Mon, 29 Jun 2026 13:59:41 -0400 From: Gregory Price To: Johannes Weiner Cc: 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 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: <20260629163337.1264881-1-hannes@cmpxchg.org> On Mon, Jun 29, 2026 at 12:33:37PM -0400, Johannes Weiner wrote: > Neha reports that mapped shmem aren't considered for NUMA balancing, > noting convergence problems and bandwidth bottlenecking for cachelib > based workloads on tiered memory systems. > > Looking at the code and going through the git history, this doesn't > actually seem intentional: > > Commit fc3147245d19 ("mm: numa: Limit NUMA scanning to migrate-on-fault > VMAs") added a vma_policy_mof() gate to task_numa_work() so VMAs whose > policy lacks MPOL_F_MOF are skipped from NUMA balancing scans. The > motivation was a real usecase: Oracle was pinning shared segments with > mbind(MPOL_BIND) so trapping faults was both expensive and pointless. > > The handling of NULL from vm_ops->get_policy, however, treated "user > explicitly opted out" the same as "user never specified anything." For > VMAs whose shared policy is absent - the common case for shmem - the > scan was disabled too. > > This issue is old. It probably hurts less in conventional NUMA. But it's > very noticable on tiered systems, where entire tmpfs workingsets can get > stuck on lower-bandwidth memory. > Eugh. Demotions don't care about mempolicy, so opting shmem out of NUMA balancing and mbind'ing on a tiered system is just full sadness. This is all just more evidence that demotion needs to be completely redone, it's creating a mess of undefined behavior for memory placement. > Fix this by having vma_policy_mof() use __get_vma_policy() directly, and > thereby handle the fallback to task policy (-> preferred_node_policy() > has MPOL_F_MOF per default). Every other consumer of vm_ops->get_policy > already handles it this way, the scan-eligibility check was the outlier. > > This preserves Mel's intended fix: don't scan stuff the user explicitly > pinned. But allow default policy vmas to participate in balancing. > > Reported-by: Neha Gholkar > Tested-by: Neha Gholkar > Fixes: fc3147245d19 ("mm: numa: Limit NUMA scanning to migrate-on-fault VMAs") > Signed-off-by: Johannes Weiner Reviewed-by: Gregory Price