[PATCH v3 00/16] arch_topology: Updates to add socket support and fix cluster ids
Gavin Shan
gshan at redhat.com
Tue May 31 20:49:07 PDT 2022
Hi Sudeep,
On 5/25/22 4:14 PM, Sudeep Holla wrote:
> This version updates cacheinfo to populate and use the information from
> there for all the cache topology. Sorry for posting in the middle of
> merge window but better to get this tested earlier so that it is ready
> for next merge window.
>
> This series intends to fix some discrepancies we have in the CPU topology
> parsing from the device tree /cpu-map node. Also this diverges from the
> behaviour on a ACPI enabled platform. The expectation is that both DT
> and ACPI enabled systems must present consistent view of the CPU topology.
>
> Currently we assign generated cluster count as the physical package identifier
> for each CPU which is wrong. The device tree bindings for CPU topology supports
> sockets to infer the socket or physical package identifier for a given CPU.
> Also we don't check if all the cores/threads belong to the same cluster before
> updating their sibling masks which is fine as we don't set the cluster id yet.
>
> These changes also assigns the cluster identifier as parsed from the device tree
> cluster nodes within /cpu-map without support for nesting of the clusters.
> Finally, it also add support for socket nodes in /cpu-map. With this the
> parsing of exact same information from ACPI PPTT and /cpu-map DT node
> aligns well.
>
> The only exception is that the last level cache id information can be
> inferred from the same ACPI PPTT while we need to parse CPU cache nodes
> in the device tree.
>
> P.S: I have not cc-ed Greg and Rafael so that all the users of arch_topology
> agree with the changes first before we include them.
>
> v2[2]->v3:
> - Dropped support to get the device node for the CPU's LLC
> - Updated cacheinfo to support calling of detect_cache_attributes
> early in smp_prepare_cpus stage
> - Added support to check if LLC is valid and shared in the cacheinfo
> - Used the same in arch_topology
>
> v1[1]->v2[2]:
> - Updated ID validity check include all non-negative value
> - Added support to get the device node for the CPU's last level cache
> - Added support to build llc_sibling on DT platforms
>
> [1] https://lore.kernel.org/lkml/20220513095559.1034633-1-sudeep.holla@arm.com
> [2] https://lore.kernel.org/lkml/20220518093325.2070336-1-sudeep.holla@arm.com
>
> Sudeep Holla (16):
> cacheinfo: Use of_cpu_device_node_get instead cpu_dev->of_node
> cacheinfo: Add helper to access any cache index for a given CPU
> cacheinfo: Move cache_leaves_are_shared out of CONFIG_OF
> cacheinfo: Add support to check if last level cache(LLC) is valid or shared
> cacheinfo: Allow early detection and population of cache attributes
> arch_topology: Add support to parse and detect cache attributes
> arch_topology: Use the last level cache information from the cacheinfo
> arm64: topology: Remove redundant setting of llc_id in CPU topology
> arch_topology: Drop LLC identifier stash from the CPU topology
> arch_topology: Set thread sibling cpumask only within the cluster
> arch_topology: Check for non-negative value rather than -1 for IDs validity
> arch_topology: Avoid parsing through all the CPUs once a outlier CPU is found
> arch_topology: Don't set cluster identifier as physical package identifier
> arch_topology: Drop unnecessary check for uninitialised package_id
> arch_topology: Set cluster identifier in each core/thread from /cpu-map
> arch_topology: Add support for parsing sockets in /cpu-map
>
> arch/arm64/kernel/topology.c | 14 -----
> drivers/base/arch_topology.c | 92 +++++++++++++++++----------
> drivers/base/cacheinfo.c | 114 +++++++++++++++++++++-------------
> include/linux/arch_topology.h | 1 -
> include/linux/cacheinfo.h | 3 +
> 5 files changed, 135 insertions(+), 89 deletions(-)
>
I tried this series on virtual machine where ACPI is enabled and looks good.
Especially for PATCH[10], resolving the issue I have. So I provided my tested-by
tag for it. Besides, I checked the changes related to ACPI part and looks to
me either after the mentioned nits fixed. I leave the changes related to device-tree
to be reviewed by the experts :)
Thanks,
Gavin
More information about the linux-riscv
mailing list