<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
I understand your concern. KFD currently only reports one L2
instance, but not every L2 instance. If customers want to have more
detail in all available L2 info, we probably can change the logic in
this function, but it is not related to my change. My change is
based on current kfd logic and fixes missing L2 issue.<br>
<br>
Thanks,<br>
Eric<br>
<br>
<div class="moz-cite-prefix">On 2025-02-06 11:37, Lazar, Lijo wrote:<br>
</div>
<blockquote type="cite" cite="mid:DS0PR12MB78048C1038DC5F279EF24E2A97F62@DS0PR12MB7804.namprd12.prod.outlook.com">
<p style="font-family:Calibri;font-size:10pt;color:#008000;margin:5pt;font-style:normal;font-weight:normal;text-decoration:none;" align="Left">
[Public]<br>
</p>
<br>
<div>
<div dir="auto"><span dir="auto" style="font-family: -apple-system, HelveticaNeue; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Yes,
the problem is that. If a node has 2 XCCs, it should report
the L2 of each separately with the number of CUs sharing
each L2.</span>
<div dir="auto" style="font-family: -apple-system, HelveticaNeue; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="auto" style="font-family: -apple-system, HelveticaNeue; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
In this, it appears to loop through and find the first
non-zero of all XCCs of a node and not based on the first
non-zero per XCC basis. It makes a difference in number of
L2 instances available.</div>
<div dir="auto" id="x_ms-outlook-mobile-signature" style="font-family: -apple-system, HelveticaNeue; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<div dir="auto"><br>
</div>
</div>
</div>
<div id="ms-outlook-mobile-signature" dir="auto">
<div><br>
</div>
<div dir="auto">Thanks,</div>
<div dir="auto">Lijo</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Huang, JinHuiEric
<a class="moz-txt-link-rfc2396E" href="mailto:JinHuiEric.Huang@amd.com"><JinHuiEric.Huang@amd.com></a><br>
<b>Sent:</b> Thursday, February 6, 2025 10:00:38 PM<br>
<b>To:</b> Lazar, Lijo <a class="moz-txt-link-rfc2396E" href="mailto:Lijo.Lazar@amd.com"><Lijo.Lazar@amd.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a><br>
<b>Subject:</b> Re: [PATCH] drm/amdkfd: fix missing L2 cache
info in topology</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
On 2025-02-06 10:14, Lazar, Lijo wrote:<br>
><br>
> On 1/29/2025 8:50 PM, Eric Huang wrote:<br>
>> In some ASICs L2 cache info may miss in kfd
topology,<br>
>> because the first bitmap may be empty, that
means<br>
>> the first cu may be inactive, so to find the
first<br>
>> active cu will solve the issue.<br>
>><br>
>> Signed-off-by: Eric Huang
<a class="moz-txt-link-rfc2396E" href="mailto:jinhuieric.huang@amd.com"><jinhuieric.huang@amd.com></a><br>
>> ---<br>
>> drivers/gpu/drm/amd/amdkfd/kfd_topology.c |
18 ++++++++++++++++--<br>
>> 1 file changed, 16 insertions(+), 2
deletions(-)<br>
>><br>
>> diff --git
a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c<br>
>> index 4936697e6fc2..73d95041a388 100644<br>
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c<br>
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c<br>
>> @@ -1665,17 +1665,31 @@ static int
fill_in_l2_l3_pcache(struct kfd_cache_properties
**props_ext,<br>
>> int cache_type,
unsigned int cu_processor_id,<br>
>> struct kfd_node
*knode)<br>
>> {<br>
>> - unsigned int cu_sibling_map_mask;<br>
>> + unsigned int cu_sibling_map_mask = 0;<br>
>> int first_active_cu;<br>
>> int i, j, k, xcc, start, end;<br>
>> int num_xcc =
NUM_XCC(knode->xcc_mask);<br>
>> struct kfd_cache_properties *pcache =
NULL;<br>
>> enum amdgpu_memory_partition mode;<br>
>> struct amdgpu_device *adev =
knode->adev;<br>
>> + bool found = false;<br>
>> <br>
>> start = ffs(knode->xcc_mask) - 1;<br>
>> end = start + num_xcc;<br>
>> - cu_sibling_map_mask =
cu_info->bitmap[start][0][0];<br>
>> +<br>
>> + /* To find the bitmap in the first active
cu */<br>
>> + for (xcc = start; xcc < end &&
!found; xcc++) {<br>
> It seems there is an assumption made here that a CU
in one XCC could<br>
> share this cache with CU in another XCC. This is
not true for GFX 9.4.3<br>
> SOCs. In those, a CU in XCC0 doesn't share L2 with
CU in XCC1.<br>
In KFD topology we only report L2 cache info of the
first active cu in A <br>
XCC, which could be XCC0 or XCC1. It is generic for L2
info in the <br>
certain XCP/kfd node, and not specific for every XCC, so
it doesn't mean <br>
the L2 cache found in XCC0 can be shared with XCC1, it
only means there <br>
is L2 cache in this kfd node.<br>
<br>
Regards,<br>
Eric<br>
><br>
> Thanks,<br>
> Lijo<br>
><br>
>> + for (i = 0; i <
gfx_info->max_shader_engines && !found; i++)
{<br>
>> + for (j = 0; j <
gfx_info->max_sh_per_se && !found; j++) {<br>
>> + if
(cu_info->bitmap[xcc][i % 4][j % 4]) {<br>
>> +
cu_sibling_map_mask =<br>
>> +
cu_info->bitmap[xcc][i % 4][j % 4];<br>
>> + found =
true;<br>
>> + }<br>
>> + }<br>
>> + }<br>
>> + }<br>
>> +<br>
>> cu_sibling_map_mask &=<br>
>> ((1 <<
pcache_info[cache_type].num_cu_shared) - 1);<br>
>> first_active_cu =
ffs(cu_sibling_map_mask);<br>
<br>
</div>
</span></font></div>
</div>
</blockquote>
<br>
</body>
</html>