From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (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 D436B478870 for ; Tue, 18 Aug 2026 13:30:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787059844; cv=none; b=GsCfhNqE+WAE7rzXog0+f4bvkIAn5Yi//J2Eb+lEj43fFo1qKDjdSyiinJAMnfKYxI32uORVmvXJXRVHC//gwi8w1k/0xEJb+aYYDsILzYP1AKsGXZHlegDkNPX8J3ryd2IpBkww8U/Ovk8PPBv1iBXrFpTb005C1XZi+UXJSc4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787059844; c=relaxed/simple; bh=9EtrV7OjP64RmR5TwTSWprliKDtLV5/e6pRMrGJB82k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LR56WnLtYdbmxjgKPWqQO9PrpstfKxFEEJl8oMqk32A8uQzewKlcSTV082A4AZXAHRf8EVM6X7BFnS7RBwH8XR4A+CMTvFhOK9Cy/BOerenIMXpBTXkvjm5cXG/aE+Jqwsl7OMxBvjdYTmV8k1Sh50TsVpL7FH56UeJg/k/bA8s= 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=GynkVWkj; arc=none smtp.client-ip=209.85.219.47 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="GynkVWkj" Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-908934450cdso35412226d6.1 for ; Tue, 18 Aug 2026 06:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1787059839; x=1787664639; 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=ax6pSQ+/xfd4HZ06hVopmXYjHWPwUVuXeBPTbOtm2CI=; b=GynkVWkjCLAbEJM1rQzLwg0o00h0x5fGGFeLcoDzJR9wG3akSbv2KUuhmjFmAeAG7F KoCiQh6u0GeLBYqQjqks7eM5OT5FO4kIAxJxBLH8qLZucJt3E+fA6EsLCNjBGt+OJ+wB 4nuhtFJUyUiNx11BSQcxbZM0c9mZnZ6aYvJ24B6vNyJ8JEaQ+/TDjuIZTqWouIH480rh Ard0z85prpSfrlATkGVbC/qq0AK92+ob3AOh/tJb0tB2HSh0LOm0zOw1c5i0OSx5rRoq Lw78Mhdmeg9MFsdz7LqY6QXhPqk06smk3IK87VLqIjhzluFBDmCPu46HKVbx/N9ZiWSg TmeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787059839; x=1787664639; 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=ax6pSQ+/xfd4HZ06hVopmXYjHWPwUVuXeBPTbOtm2CI=; b=AIoK3cOsOVV0PnKeR8Qj3oue0pfPbhLwiI5Mhm0aj2H1gWhVgt2ANiE16B+rey4Xfw sT0swSZlKC2arxXTWMzE9bIr9r1lg6Qa2MEETRLezqGFiUyXIh9Td1CeXmqItFNCOXod ULT0COlQygAt7uiKM7DjXN+AQnYc2cBa9W0mvub65xmTBTPcrMevhuAF53DovoAd9hwx Avs1unYjN8AutT2hFlBmr16/3ntwuBi+Y4Yb0Gnhw+JOFGvsM9kCKmqxp1O9H9OGHNvb tGXyf8c67bHYGU0iGHSw5x84gxGHQD3q8Z3eG6bbuMms+Naa/tJPfxgmnk5hn7MMmoVr nMPg== X-Forwarded-Encrypted: i=1; AHgh+RpLsrmdPhnquwyYM3JmjS7jCtmNt+QNk/8PFSiF4pUhQAMUFlOwW4Z9c/drRd31z9pQ5r0KzAOclki9PVw=@vger.kernel.org X-Gm-Message-State: AOJu0Yyj84TXcUVfqoMhq7Hmi99ep2g/7nohq7Ab31a399dzWm3qxg2v K+xT8cjdUzHrQ6uSgZdSkCczxaDVZMY03j6ffotyoIAE/Hh2lgSMO8HU75/MdWwlVU8= X-Gm-Gg: AR+sD11NCXGLGt1ZM4meETwUU47eqs1R87zYNFn95X3lUq5lPAHm70wIbbyfto9kpXh 9oFeYM0/w8MSj+GeEJv2nRSnFcPTlB3d+bvwNO98aJ0vSfdIXKTcFQ+S7dJTQr0XRi9ThceclKM mZYGqQ0IDoImxuUL5fZ2jsKh5PjyHNjJirQlYb//NNK1ttTlg7ri8r91IquE8vl0jBSDSSKnWzH lIRYC7pzU+FSISlXddssSHNowZcwb4RzqeztcXSAgQvZIt2+fwORbYRGx/2K/zrKSlfDGfeO165 5UWzovGmZiJI/vsBanYKGA1ycc6v9ivKLxNIrNXrKwgpDxkrI36fahIASG8f99PY3lfNS9DVca+ KBYMretDBWpxKKvGXn0Tj8iWb5ptn4hGVZz1fa+rzoXPhJLuE/MmbwMHsthIORvyKjpEWdlzDc8 eBPuZhKFp3uWh9NbBErISlMaQo6lzr4ASVHX65I/AMxtnnicIj7tXE6WamTqb50zR1eiacSdB6v kuAuH8D70RbpWF3WCmmeKS19Y3DA68EW5ADXcVT7BzL X-Received: by 2002:a05:6214:498a:b0:908:a54a:5b29 with SMTP id 6a1803df08f44-90a91deefccmr394858816d6.24.1787059838767; Tue, 18 Aug 2026 06:30:38 -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-90c4580fcc4sm32688846d6.4.2026.08.18.06.30.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 06:30:38 -0700 (PDT) Date: Tue, 18 Aug 2026 09:30:36 -0400 From: Gregory Price To: Rakie Kim Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com, david@kernel.org, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, dave@stgolabs.net, jic23@kernel.org, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, harry@kernel.org, kernel_team@skhynix.com, honggyu.kim@sk.com, yunjeong.mun@sk.com Subject: Re: [PATCH 0/4] mm/mempolicy: introduce package-aware weighted interleave Message-ID: References: <20260818060201.1907-1-rakie.kim@sk.com> 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: <20260818060201.1907-1-rakie.kim@sk.com> On Tue, Aug 18, 2026 at 03:01:58PM +0900, Rakie Kim wrote: > On Mon, 17 Aug 2026 12:19:51 -0400 Gregory Price wrote: > > > I have some concerns with the now additional filtering mechanism > > introdced into the allocation stack, but fundamentally I think this is > > a *better* solution than a straight weight-matrix. > > About the cost of the filter: when the toggle is off, the filter does > not run. When it is on, node selection needs a nodemask filtering > step, but in my tests the overhead was negligible. I will look at > this part further and check whether there is more room to optimize. > Not concerned about the performance, concerned about how complicated the mempolicy - cgroup - zonelist - page_alloc interaction already is, and then adding another filtering mechanism on top. Today we have: 1) cpuset constrains mempolicy (nodemask remaps) 2) cpuset constrains zonelist walks 3) mempolicy nodemask constrains zonelist walks 4) memory-tiers.c nodemask constrains zonelist walks for demotion 5) zonelist membership constrains allocation access 6) a bunch of corner conditions that violate 1-3 for the sake of forward progress now we're adding: 7) memory-tiers.c nodemask constrains mempolicy nodemask except when it doesn't, because fallbacks occurred hard enough It's already un-intuitive how and when memory lands on certain nodes. To be clear, I'm not saying this idea is bad - either as-is or in some other form - just that adding another nodemask filtering path is making it harder and harder to understand what lands where. Mostly starting to wonder if we're reaching the point where the page allocator needs to take something a little more descriptive than a nodemask to dictate placement. ~Gregory