<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix"> <blockquote type="cite"> It's not a high priority as I'm not aware of any applications that actually make use of the cache information. </blockquote> Which raises the question why we have done this in the first place? When nobody is using it could we just remove the interface? Regards, Christian. Am 16.04.19 um 05:24 schrieb Kuehling, Felix: </div> <blockquote type="cite" cite="mid:87066753-b061-da00-9795-ca38ada81622@amd.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> On x86 we use the apicid to associate caches with CPU cores. See the Thunk code in libhsakmt/src/topology.c (static void find_cpu_cache_siblings()). If we used a different way to identify CPU cores, I think that would break. This code in the Thunk is x86-specific as it uses the CPUID instruction. We don't have equivalent code for ARM. So for ARM it doesn't really matter much, how you count your CPU cores in the CRAT table. I think eventually we want to get rid of that fragile CPUID code in the Thunk and get the cache information in kernel mode and report it to user mode through the KFD topology sysfs filesystem. Then we could also move away from using apicids as CPU IDs on x86. It's not a high priority as I'm not aware of any applications that actually make use of the cache information. Regards, Felix <div class="moz-cite-prefix">On 2019-04-15 22:39, Hillf Danton wrote: </div> <blockquote type="cite" cite="mid:84019ce7-4bda-4740-81f7-bfeb06f11b13@BY2NAM03FT064.eop-NAM03.prod.protection.outlook.com"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> <div class="WordSection1"> Hi folks <o:p> </o:p> In commit d1c234e2cd, arm64 is granted to build kfd. Currently, it is physical cpu id that is used for building the x86_64 vcrat, but logical cpu id is used instead for arm64, though the function name requires apicid. Can we use the physical id for both arches if it really has an up-hand over the logical one, as the following tiny diff represents? <o:p> </o:p> --- linux-5.1-rc4/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 2019-04-16 07:55:56.611685400 +0800 +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 2019-04-16 09:16:50.506126600 +0800 @@ -1405,11 +1405,7 @@ static int kfd_cpumask_to_apic_id(const first_cpu_of_numa_node = cpumask_first(cpumask); if (first_cpu_of_numa_node >= nr_cpu_ids) return -1; -#ifdef CONFIG_X86_64 - return cpu_data(first_cpu_of_numa_node).apicid; -#else - return first_cpu_of_numa_node; -#endif + return cpu_physical_id(first_cpu_of_numa_node); } /* kfd_numa_node_to_apic_id - Returns the APIC ID of the first logical processor -- <o:p> </o:p> <o:p> </o:p> Or is logical cpu id enough to do the work, with some cosmetic applied to the function names(not included in the following simple diff yet)? <o:p> </o:p> thanks Hillf <o:p> </o:p> <o:p> </o:p> --- linux-5.1-rc4/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 2019-04-16 07:55:56.611685400 +0800 +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 2019-04-16 09:18:24.546578400 +0800 @@ -1405,11 +1405,7 @@ static int kfd_cpumask_to_apic_id(const first_cpu_of_numa_node = cpumask_first(cpumask); if (first_cpu_of_numa_node >= nr_cpu_ids) return -1; -#ifdef CONFIG_X86_64 - return cpu_data(first_cpu_of_numa_node).apicid; -#else return first_cpu_of_numa_node; -#endif } /* kfd_numa_node_to_apic_id - Returns the APIC ID of the first logical processor --<o:p></o:p> <o:p> </o:p> </div> </blockquote> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ amd-gfx mailing list <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a></pre> </blockquote> </body> </html>