From: Gregory Price <gourry@gourry.net>
To: Honggyu Kim <honggyu.kim@sk.com>
Cc: Yunjeong Mun <yunjeong.mun@sk.com>,
kernel_team@skhynix.com, Joshua Hahn <joshua.hahnjy@gmail.com>,
harry.yoo@oracle.com, ying.huang@linux.alibaba.com,
gregkh@linuxfoundation.org, rakie.kim@sk.com,
akpm@linux-foundation.org, rafael@kernel.org, lenb@kernel.org,
dan.j.williams@intel.com, Jonathan.Cameron@huawei.com,
dave.jiang@intel.com, horen.chuang@linux.dev, hannes@cmpxchg.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-mm@kvack.org, kernel-team@meta.com
Subject: Re: [PATCH 2/2 v6] mm/mempolicy: Don't create weight sysfs for memoryless nodes
Date: Tue, 18 Mar 2025 11:13:13 -0400 [thread overview]
Message-ID: <Z9mNiWm1pNIxiu0t@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <ed0004ea-c8d6-4ba9-ba40-0c9a97d98db6@sk.com>
On Tue, Mar 18, 2025 at 08:02:46PM +0900, Honggyu Kim wrote:
>
>
> On 3/18/2025 5:02 PM, Yunjeong Mun wrote:
>
> Some simple corrections here. host-bridge{0-3} above aren't detected from CEDT.
> The corrected structure is as follows.
>
> rootport/
> ├── socket0
> │ ├── cross-host-bridge0 -> SRAT && CEDT (interleave on) --> NODE 2
> │ │ ├── host-bridge0
> │ │ │ ├── cxl0 -> CEDT
node 4
> │ │ │ └── cxl1-> CEDT
node 5
> │ │ └── host-bridge1
> │ │ ├── cxl2 -> CEDT
node 6
> │ │ └── cxl3 -> CEDT
node 7
> │ └── dram0 -> SRAT ---------------------------------------> NODE 0
> └── socket1
> ├── cross-host-bridge1 -> SRAT && CEDT (interleave on)---> NODE 3
> │ ├── host-bridge2
> │ │ ├── cxl4 -> CEDT
node 8
> │ │ └── cxl5 -> CEDT
node 9
> │ └── host-bridge3
> │ ├── cxl6 -> CEDT
node 10
> │ └── cxl7 -> CEDT
node 11
> └── dram1 -> SRAT ---------------------------------------> NODE 1
>
This is correct and expected.
All of these nodes are "possible" depending on how the user decides to
program the CXL decoders and expose memory to the page allocator.
In your /sys/bus/cxl/devices/ you should have something like
decoder0.0 decoder0.1 decoder0.2 decoder0.3
decoder0.4 decoder0.5 decoder0.6 decoder0.7
decoder0.8 decoder0.9
These are the root decoders that should map up directly with each CEDT
CFMWS entry.
2 of them should have interleave settings.
If you were to then program the endpoint and hostbridge decoders with
the matching non-interleave address values from the other CEDT entries,
you could bring each individual device online in its own NUMA node.
Or, you can do what you're doing now, and program the endpoints to map
to the 2 cross-host bridge interleave root decoders.
So your platform is giving you the option of how to online your devices,
and as such it needs to mark nodes as "possible" even if they're unused.
~Gregory
next prev parent reply other threads:[~2025-03-18 15:13 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250228001631.1102-1-yunjeong.mun@sk.com>
2025-02-26 21:35 ` [PATCH 1/2 v6] mm/mempolicy: Weighted Interleave Auto-tuning Joshua Hahn
2025-02-26 21:35 ` [PATCH 2/2 v6] mm/mempolicy: Don't create weight sysfs for memoryless nodes Joshua Hahn
2025-02-27 2:32 ` Honggyu Kim
2025-02-27 3:20 ` Honggyu Kim
2025-03-03 21:56 ` Joshua Hahn
2025-03-04 12:53 ` Honggyu Kim
2025-03-03 16:19 ` Gregory Price
2025-03-04 13:03 ` Honggyu Kim
2025-03-04 16:16 ` Gregory Price
2025-03-04 16:29 ` Gregory Price
2025-03-06 12:39 ` Honggyu Kim
2025-03-06 17:32 ` Gregory Price
2025-03-07 11:46 ` Honggyu Kim
2025-03-07 17:51 ` Gregory Price
2025-03-10 12:26 ` Honggyu Kim
2025-03-10 14:22 ` Gregory Price
2025-03-11 2:07 ` Yunjeong Mun
2025-03-11 2:42 ` Gregory Price
2025-03-11 4:02 ` Yunjeong Mun
2025-03-11 4:42 ` Gregory Price
2025-03-11 9:51 ` Yunjeong Mun
2025-03-11 15:52 ` Gregory Price
2025-03-18 8:02 ` Yunjeong Mun
2025-03-18 11:02 ` Honggyu Kim
2025-03-18 15:13 ` Gregory Price [this message]
2025-03-19 9:56 ` Yunjeong Mun
2025-03-19 14:54 ` Gregory Price
2025-02-28 0:16 ` [PATCH 1/2 v6] mm/mempolicy: Weighted Interleave Auto-tuning yunjeong.mun
2025-02-28 6:39 ` Yunjeong Mun
2025-02-28 16:24 ` Joshua Hahn
2025-03-04 21:56 ` Joshua Hahn
2025-03-04 22:22 ` Joshua Hahn
2025-03-05 9:49 ` Yunjeong Mun
2025-03-05 16:28 ` Joshua Hahn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9mNiWm1pNIxiu0t@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=honggyu.kim@sk.com \
--cc=horen.chuang@linux.dev \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=kernel_team@skhynix.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
--cc=rakie.kim@sk.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yunjeong.mun@sk.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox