All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dhruv B <dhruv.b@linux.ibm.com>
To: amd-gfx@lists.freedesktop.org,
	Felix Kuehling <Felix.Kuehling@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Alex Deucher <alexdeucher@gmail.com>,
	christian.koenig@amd.com, Philip Yang <yangp@amd.com>
Cc: David.YatSin@amd.com, Kent.Russell@amd.com,
	Ritesh Harjani <ritesh.list@gmail.com>,
	Vaidyanathan Srinivasan <svaidy@linux.ibm.com>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	donettom@linux.ibm.com, dhruv.b@linux.ibm.com
Subject: [PATCH 0/3] drm/amdkfd: Add support for discontiguous and CPU-less NUMA topologies
Date: Mon,  5 Oct 2026 19:30:20 +0530	[thread overview]
Message-ID: <cover.1791208447.git.dhruv.b@linux.ibm.com> (raw)

This series fixes VCRAT generation in AMDKFD for systems that do not
provide a CRAT table and where the driver generates a Virtual CRAT
(VCRAT) for the CPU topology.

The current implementation uses for_each_online_node() to iterate over
NUMA nodes and assigns proximity domain IDs sequentially (0, 1, 2, ...)
regardless of the actual NUMA node IDs. It also assumes that every online
NUMA node contains both CPUs and memory, unconditionally emitting
Compute Unit and Memory CRAT subtypes for each node.

These assumptions break on systems with:

  Discontiguous (sparse) NUMA node IDs
  CPU-less NUMA nodes
  Memory-less NUMA nodes

For example:

  available: 3 nodes (0,2-3)

  node 0: CPUs present
  node 2: CPU-less
  node 3: CPU-less

In this case, the existing code iterates over nodes 0, 2 and 3 and
assigns proximity domains 0, 1 and 2 respectively, instead of 0, 2
and 3. The mismatch between NUMA node IDs and proximity domain IDs
results in an inconsistent KFD topology and causes topology parsing to
fail with:

  amdgpu 0038:12:00.0: Error parsing VCRAT
  kfd kfd: Error adding device to topology
  kfd kfd: Error initializing KFD node

To fix the proximity domain mismatch, the VCRAT generation loop is
changed to iterate over the complete NUMA node ID range up to the last
online node, incrementing num_domains for every node ID in the range.
This preserves a direct 1:1 mapping between NUMA node ID and proximity
domain ID, while skipping resource entry creation for offline or
unpopulated node IDs.

To fix the unconditional subtype emission, explicit guards are added so
that Compute Unit entries are only written for nodes that have valid CPU
cores (kfd_numa_node_to_apic_id() != -1), and Memory entries are only
written for nodes that actually contain memory (node_state(N_MEMORY)).
This prevents invalid or empty CRAT subtype entries from being emitted
for CPU-less, memory-less, or empty NUMA nodes.

This series consists of the following patches:

Patch 1 removes unused code in the CRAT initialization path.

Patch 2 fixes the proximity domain mismatch by iterating through the
complete NUMA node ID range and preserving a direct NUMA-node-to-
proximity-domain mapping.

Patch 3 restricts Compute Unit and Memory CRAT subtype entries to NUMA
nodes that actually have the corresponding resources.

Dhruv B (3):
  drm/amdkfd: Remove unused code in CRAT initialization
  drm/amdkfd: Add support for discontiguous NUMA node topology
  drm/amdkfd: Restrict CU and memory entries to resource nodes

 drivers/gpu/drm/amd/amdkfd/kfd_crat.c     | 61 ++++++++++++-----------
 drivers/gpu/drm/amd/amdkfd/kfd_crat.h     |  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 11 +---
 3 files changed, 35 insertions(+), 39 deletions(-)

-- 
2.54.0 (Apple Git-157)


             reply	other threads:[~2026-10-06  7:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05 14:00 Dhruv B [this message]
2026-10-05 14:00 ` [PATCH 1/3] drm/amdkfd: Remove unused code in CRAT initialization Dhruv B
2026-10-05 20:42   ` Felix Kuehling
2026-10-05 14:00 ` [PATCH 2/3] drm/amdkfd: Add support for discontiguous NUMA node topology Dhruv B
2026-10-05 20:18   ` Felix Kuehling
2026-10-06 12:31     ` Dhruv Bhogaonkar
2026-10-05 14:00 ` [PATCH 3/3] drm/amdkfd: Restrict CU and memory entries to resource nodes Dhruv B

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=cover.1791208447.git.dhruv.b@linux.ibm.com \
    --to=dhruv.b@linux.ibm.com \
    --cc=David.YatSin@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=Kent.Russell@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=donettom@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=simona@ffwll.ch \
    --cc=svaidy@linux.ibm.com \
    --cc=yangp@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.