From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (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 922E5428473 for ; Wed, 1 Jul 2026 15:33:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782920026; cv=none; b=WzNmtQGDtlGvC7BmgTGQezAdB33OYx926IS1v+mRVM4tOB9tSiDt6jHY91nwmldFh4KPnzl4NpplYXLs5G9ArzZZde2A6rPU4jJkEHUav/fVn78H07qe6JRWvVHW9NXscIeKlhTgatLTzkgE7jGQVeydoI5UMssiT5FgcCkzo3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782920026; c=relaxed/simple; bh=kHfypmrM55CNSiUY7oqkSt7jXILILgKR4/dVQ+RpOMQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RSuIczYqyVYRI54uhfAlpR+Z+mJGbzIEIyQAsiDW27Xr0RMgmHydslYLm3/9PGagPTaUWyIfRkTHYAbupU3vKwgEAV+sHtli/knroy0Mesi+a5GonRPgg8cpZbDgpv9LVypb9sNvYHCQ0bjK6WHeG0VMlSE/p8sBhISTsrCXfbE= 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=rBRxdxEO; arc=none smtp.client-ip=209.85.219.52 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="rBRxdxEO" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-8efef6533aaso6462186d6.0 for ; Wed, 01 Jul 2026 08:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1782920023; x=1783524823; 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=CG5JVx2LTAX9k3jWV3TDZg5C43pEsJtl7lkUI2V0PbQ=; b=rBRxdxEOSk9xQMYSpDvqm0j/LVE78nvLNcS+tO0lVFFUuEvfpuIdfxDfvtTx8y3Rke 0XkBi7BQxhgnScr0eZ251x6oWoYUbTSItcDVD+T4ax6brSQ946kldRHbXBwlZXBP1ukU j4K1Qeru1MA6HwvnmU8HV3R/ao6X1RbQeOi9Gl5ARjGGZ4XhG5+E22+N02wd3BjpDiWJ h3d6Oz0bGT9/rlWjAOeuX0sSM/KyEbdjkD3gHmekY+nV/veZ8+4m8eiUdqnmnsqP2QXy WahomyxSscazHdffaaxXeWXz8maw0RZR0h0ibqY3LvcAHP9uOTv0MVl7gKXTXriOAt9Q ExUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782920023; x=1783524823; 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=CG5JVx2LTAX9k3jWV3TDZg5C43pEsJtl7lkUI2V0PbQ=; b=QmtoJ1NdDsfVZ/B2gfhDSDuZh2nQOfSkXd2QRmU1o0JS/rukbiDOEUnuQCMjyqnoYu 3wdB9G5PhQn9hFnHdOp/2ncLwTwYJdtg9kyYS11M87P36I5fFHpLiLBRnq7NX8MPRjfk 5IeeKLEmci34BwWgmoVKyTopQYmXKp2r2Jz5tMtUZDaGgqdzb2J8uirm69RYPrRBwOms bnYtK6626qoVLFXyVrsPm+e1b7dPhpyv+JVaEvXaw2cB67EEntnwzYy4S5sZEtSpzMkZ vb2bxGwACLn1kG1d5qGw1tWARX9A4BG2T3Ek/cQic3sqWRweSe4NXyKjfxAsjefYQpFO E9lA== X-Forwarded-Encrypted: i=1; AHgh+Rqvm2G3nkal176tj6dlS2NqNTUvBeFzZzWbtnfRpbPOir+T0s46Q8uFpC/ypwjjcKqX045rHcWLJutn9V0=@vger.kernel.org X-Gm-Message-State: AOJu0YzUEIFD3rCpWCHcpRz0FcDOpoc5o8ylwkcxrPpaWSfCiYBuZFxQ CdfCe9wNMiNRE7uLIM5sJ2vrUPFY1sMv2lc3i+CFJ4pkVaLarwnYSF7+WErhu1xBGKI= X-Gm-Gg: AfdE7cnDfYfsNnymt+h+hbgT3exF4vcM8T9nKO9qfbIh8+nlUuY0cnmeS8pRYP4IwDy 2rB8Y6Q1ZLb7FbcDeGa8KFbgcXBU53aiTsmHADq/euC76NlH9GDZLv1ks7iYZOcqaJYjRVrEQ1n 34cOXY0NWtR58UsNDwiBYAkbSThMo823Zym2xYkrwTzG9lrt1IoAQTOmH9dJySYnvGQdGDo5jdP wdabsJJ6hJBnjzAeVaRwiK6FWPbAi1YR/ZHdO+HtzPalc4ihcPcxQkUL6bOJQQSWQCp5wZJmep7 wOwCXsqRWsRw7mSfXfFhQ/ARpuRl5quJ3yy9xWG+miz1zfgYQ1tNbSaWnXEF8xA6JDqfQhWMQVz 9LPNZBm35cfWib9GlYx2rPRMgClLvkcn6uZFc+6YzshV9XTY6Dz8B1embGy5aGR6jd5syE5C2B8 MhzQrQvDYP1nYUqk+2gU40Xs2IdQiMiogiRaQtsclMCMr/8KfsupqERqfbswjWW1k1XTYT X-Received: by 2002:a05:6214:4890:b0:8f3:9e41:e965 with SMTP id 6a1803df08f44-8f42538719dmr18349606d6.50.1782920023478; Wed, 01 Jul 2026 08:33:43 -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 6a1803df08f44-8f3611d7ea8sm23639646d6.31.2026.07.01.08.33.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 08:33:43 -0700 (PDT) Date: Wed, 1 Jul 2026 11:33:38 -0400 From: Gregory Price To: "Huang, Ying" Cc: Johannes Weiner , Andrew Morton , David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , 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> <87h5mkz33h.fsf@DESKTOP-5N7EMDA> <877bnfynsr.fsf@DESKTOP-5N7EMDA> 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: <877bnfynsr.fsf@DESKTOP-5N7EMDA> On Wed, Jul 01, 2026 at 07:03:32PM +0800, Huang, Ying wrote: > Gregory Price writes: > > > On Tue, Jun 30, 2026 at 07:20:50PM +0800, Huang, Ying wrote: > >> Gregory Price writes: > >> > >> [snip] > >> > >> > 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. > >> > >> It's hard to respect mempolicy during demotion in the current > >> implementation. Do you have any ideas on how to improve this? > >> > > > > I think it's feasible we could respect per-vma mempolicies, but not > > per-task. That would at least make this particular interaction less > > painful and mbind() would do what you'd expect. It is a bit racy, > > but with MPOL_MF_MOVE_ALL the user can get what they actually want. > > Yes. Per-vma mempolicy support is possible. > > > I think task-wide mempolicy is problematic and generally a bad idea > > on tiered systems, maybe it's ok if we simply document task policies > > are not respected on tiered systems? > > Anyway, it's convenient to use numactl to manage mempolicy. > It can be, but there's also many footguns with task-wide policy. Something i found while seeing if i could make ZONE_NORMAL nodes more reliably hotpluggable: diff --git a/lib/stackdepot.c b/lib/stackdepot.c index dd2717ff94bf..9ceeb56574ef 100644 --- a/lib/stackdepot.c +++ b/lib/stackdepot.c @@ -682,7 +682,15 @@ depot_stack_handle_t stack_depot_save_flags(unsigned long *entries, * we won't be able to do that under the lock. */ if (unlikely(can_alloc && !READ_ONCE(new_pool))) { - page = alloc_pages(gfp_nested_mask(alloc_flags), + /* + * The stack depot pool is a global, never-freed allocation. + * Use alloc_pages_node() on the CPU-local node instead of + * alloc_pages() so the pool does not inherit a transient task's + * NUMA mempolicy (e.g. MPOL_BIND to a CPU-less/bound node), which + * would strand this long-lived page on that node forever. + */ + page = alloc_pages_node(numa_node_id(), + gfp_nested_mask(alloc_flags), DEPOT_POOL_ORDER); if (page) prealloc = page_address(page); This is a global, permanently allocated, resource that inherits a task mempolicy's placement because that task *happened* to be the first one to touch it. There are many alloc_pages() calls (155 instances kernel-wide) that inherit a task mempolicy when that's probably not what we want. alloc_pages() is called in: net/, lib/, kexec_core/, drivers/, arch/ you can imagine a task setting `set_mempolicy(INTERLEAVE, ALL)` and the result is a bunch of random driver memory gets spread all over the place along with the task's heap. Is that really what the caller wanted, or did they just want userland data spread about? But at this point it's a 20 year old interface, not much we can do about it without making *someone* sad :[ I considered proposing MPOL_F_MOVABLE_ONLY to mean (roughly) "userland memory only" - and then slowly trying to migrate numactl to make this the default. > Is it possible to enable NUMA_BALANCING_MEMORY_TIERING for non-default > VMAs? If we don't enable NUMA_BALANCING_NORMAL, the overhead should be > OK because the page table entries are changed to PROTN_ONE only for > pages on the slow tier. > hmmm, will have to give this some thought. > Additionally, we may need to consider cpusets. > Direct reclaim considers cpusets for the reclaiming task (added recently), kswapd sits in its own cgroup. Cross-cpuset checks - i'm not sure how tractable that is. We ignore it for now, recognizing that if something is cross-cpuset it's some definition of shared/global object (e.g. pagecache mappings). ~Gregory