Re: [RFC] drm/amdkfd: Use logical cpu id for building vcrat
On 2019-04-16 2:44 a.m., Christian König wrote: >> >> It's not a high priority as I'm not aware of any applications that >> actually make use of the cache information. >> > Which raises the question why we have done this in the first place? > When nobody is using it could we just remove the interface? The interface for cache information in the topology has existed since KFD was first introduced for APUs. On APUs the information is contained in the CRAT table. I see no reason not to report available information to user mode. If you wanted to remove it, you'd need to prove that nobody is using it. My statement was much weaker than that. Furthermore, the cache information on CPUs is currently generated in user mode anyway. Changing the way we count CPU cores would break that existing user mode code, so we can't do that. That said, there is no kernel code to remove here. All I was saying was, that it's not a high priority to add the kernel code to populate CPU cache information in kernel mode. Regards, Felix > > Regards, > Christian. > > Am 16.04.19 um 05:24 schrieb Kuehling, Felix: >> >> 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 >> >> On 2019-04-15 22:39, Hillf Danton wrote: >>> >>> Hi folks >>> >>> 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? >>> >>> --- 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 >>> >>> -- >>> >>> 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)? >>> >>> thanks >>> >>> Hillf >>> >>> --- 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 >>> >>> -- >>> >> >> ___ >> amd-gfx mailing list >> amd-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[RFC] drm/amdkfd: Use logical cpu id for building vcrat
Hi folks 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? --- 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 -- 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)? thanks Hillf --- 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 -- ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC] drm/amdkfd: Use logical cpu id for building vcrat
It's not a high priority as I'm not aware of any applications that actually make use of the cache information. 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: 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 On 2019-04-15 22:39, Hillf Danton wrote: Hi folks 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? --- 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 -- 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)? thanks Hillf --- 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 -- ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RFC] drm/amdkfd: Use logical cpu id for building vcrat
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 On 2019-04-15 22:39, Hillf Danton wrote: Hi folks 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? --- linux-5.1-rc4/drivers/gpu/drm/amd/amdkfd/kfd_topology.c2019-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 -- 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)? thanks Hillf --- linux-5.1-rc4/drivers/gpu/drm/amd/amdkfd/kfd_topology.c2019-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 -- ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
