From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 9052E43B3D1 for ; Mon, 17 Aug 2026 16:19:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786983598; cv=none; b=otqp5kCsfn5viaxAmx/mYZgUlX2hz7WeZvUAP8yDTGZMKNt3RHu7g7NVUYmvmbE03X25eHqXpJTtqaHgG3ykiJZxjdOuAtktNIHVqaCVkW4wbGc5p/SHUzcauuH0WKlyrD4GGfx8rpMfM5uMbVu8xdyn1i4Kgppq3my+3sqAZ7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786983598; c=relaxed/simple; bh=nz9452HQkCizulHzHgH6sPXgLsUkaADhbih6+tFp8A8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bPKmWZzOqm/wsTKmxVvKpDjBIc2qMAEGJHz8Mwv99UXpyi3ZsVoNDBwK9PZzGh73NP2fqf4p6Sk1iKHz48FOz1GjiXXNcz15OLW6b1kvqxkitaKiRrhQkanu0vbRxYd+7JsTyQKlKcEFwomXsvc4P7gN0FukPL7Cf3woJh0pLK4= 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=fXvUSPwi; arc=none smtp.client-ip=209.85.222.182 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="fXvUSPwi" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-92e6a434cabso168946785a.1 for ; Mon, 17 Aug 2026 09:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1786983593; x=1787588393; 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=g79rp1EAN8LS02s21Qd/CfSeDeEXT49xOteHy0W5fBY=; b=fXvUSPwiiLw1YebLJTtdAJ+CWLPQde4QHB1KfV4EKsyE1eW9krRh3ShCiG6fL8P4E9 5PnrjumLCqIrPootoxDqEp0oYeXPOvoi97cv2s/o4MnVvfvwBKPy8ZGZBfGbskQxP1IB t401JIexZfnsHMxTwe/wk7zKFgxf7NVazvwZ9R0fckExm3B1LrNnFG369shmOTrW3gU6 M3szJZ1jXobLbZqYLo9nmMm8+q8weSrs52c7CrpQHDsQShpnFyw/1IknqxyazhYNYEMd nFaBMREejsORutE9LiOVytMx8E6/6cUuJMH0o5cD+Wj8gc0Cr9jM6vL100BblBazZiSG RIRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786983593; x=1787588393; 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=g79rp1EAN8LS02s21Qd/CfSeDeEXT49xOteHy0W5fBY=; b=Z3hBI521dixs95qfkvQOYEjNAkui+6c38RGFAL9IeZjnYk3sYV1HyPDXvtsq+jUpxc f/qzmwuyyjt4EmPeIt8W2fZMsqSP6huQPh+EElSBObVX4n4Phd/sWhkLNEEMhIC3pVpd I8EBkvek+oGSAt5Jwn9kmBT6jTKtwyTBB7U94bvpzWnd6e+tZjG20P7qOQE4A+iC6DvA XtYMnlxh7+IhLC/MQsSWsFqJ09/7mU4pI5w7XlTd1R++rouD4MIl7rutREfhxUDm7r90 S27DC5+Qzp8Nr0ZfdnVCZQBEynD6eR7aWvnwltjeLPHKR0EJLuSd9aSeeQS5JXt9hX5P oUfw== X-Forwarded-Encrypted: i=1; AHgh+Rrar8zCKiIfMDJD7DEJR28YpJHIhSh26sDYk/uHJDhtZmxwc6JUQKC4+x9vKXPndJJbFI5mqxwroZUI/ok=@vger.kernel.org X-Gm-Message-State: AOJu0YwiELhZb1+cXem24bgIItUkHZIqdttPcOTvdNcRidHE1qIPelzq X3h5YcAhzcdktDEFTEvB6zpMylWJaUSrCVNsjyS3uiNqkxi0FyinEEzrxf6EjgNk0ns= X-Gm-Gg: AR+sD12hg0lIpfE+PPSfHk5nN10rIO25oJ5I34vxSRHzuIZVGBcnN0yHGvXZ5vz+Pm6 flUGTgE/zSvVKnMUPcG9zGsyA38At8aNRySdomhH7F76weMmwhcen5sstu7Gx0yWBAejBWzx/bL rO2PvDPcQ6nfn8Tr5txar4N3nRn1UbF56/jYUerm6eS/vlLzFXlCKph+Jh/TBY14z+pRLfZr+xO ijcqLgO0SBY6IsDza4JB9E55McElGx6JTwaSglGjdlw5JEzHaI+XEYPt5X+4vPlNX4Kftb7ifYf M3xu0EWUMp1pwzZWmFkIdyqEzu9Fmca6gAF6P72Nl5V1lsKTRRtYSBMzxqm3IKcZPHfhb4iQSbC d+ZcJCzoVJCbGNnqOVGtqP6vVXQzLX/S5q9mLbbJn/ulyDTXVTXyQpuy2jPekog5SPMsFL4pXWv UF5F33ta2h0z8aSPP3QmuTWRUiqlvNFmol+eacLmAYXd74Cng6a/GsCuSeCgGL5EC0UW+EeAufy ecs0H4oyvFd9Chk9Wyx2em/XHP+GbWyiHKA1DzfG0Hq X-Received: by 2002:a05:620a:5302:b0:936:ce17:dac3 with SMTP id af79cd13be357-936d238d066mr2289883285a.40.1786983593483; Mon, 17 Aug 2026 09:19:53 -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-937033ce78csm80835485a.31.2026.08.17.09.19.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 09:19:53 -0700 (PDT) Date: Mon, 17 Aug 2026 12:19:51 -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: <20260806080936.421-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: <20260806080936.421-1-rakie.kim@sk.com> On Thu, Aug 06, 2026 at 05:09:31PM +0900, Rakie Kim wrote: > > To make this possible the kernel needs a notion of which nodes share a > package. The NUMA distance model offers only relative latencies and no > structural grouping, which is especially limiting for CXL memory nodes > that come online without an explicit package association. > The original attempt to handle cross-socket interleave tried to deal with this with a matrix for weights, but this was deemed too invasive. This brings back that matrix, but not for per-node weights - we're basically just adding an addition weighting to filter on. 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. I will need to chew on this for a bit. It seems there's non-trivial sashiko bug reports here to address anyway. > The series adds a package-aware topology layer that groups CPU and > memory-only nodes into a "memory package", built from the physical > package ids firmware reports and, for a memory-only node, an initiator > CPU node or SLIT distances. A package can contain more than one CPU node > or more than one memory-only node, so the layer maps a package to a set > of nodes rather than to a single node or a single CXL device. > When worded this way, "Package" sounds completely arbitrary and not a useful distinction. This really just sounds like an extention for the existing fallback lists to take interconnects into account. I wonder if abstract distance either: 1) already gives you what you want (the secondary weight) 2) can be twiddled in BIOS to give you what you want. > The feature is off by default and opt-in through a sysfs toggle. The > package topology itself is exposed read-only under > /sys/devices/system/package/; there is deliberately no writable > override, since a machine whose firmware describes its topology > incorrectly should be fixed in firmware. On a topology that does not > have the symmetric shape the placement relies on, enabling is refused > and any active mode degrades cleanly to the original flat behavior. The way this is written it sounds to me like this should just be the default weighted interleave behavior. We already know weighted interleave does not jive well with multi-socket systems - this just fixes that (in a more general sense, Socket => Package). ~Gregory