Hi,
Thanks for taking a look at this.
On 8/2/19 8:05 AM, Robert Richter wrote:
On 31.07.19 22:46:33, Jeremy Linton wrote:
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 9426b9aaed86..9d0e20a2ac83 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1302,11 +1302,16 @@ static inline int lpit_read_residency_count_address(u64 *address)
#endif
#ifdef CONFIG_ACPI_PPTT
+int acpi_pptt_cpu_is_thread(unsigned int cpu);
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
All those functions (exept hetero_id) are used only in
parse_acpi_topology(). So how about creating a struct with thread_id,
core_id, and cache_id (and hetero_id (?)) and have a single pptt table
parsing function that fills in all of this into that struct? This
simplifies the api and also the code.
This also shows that hetid (see arm_pmu_acpi.c) better should be
stored in cpu_topology[] too and thus being parsed with the other
parameters as well and made accessible from there by a helper.
I think the idea here was to avoid an additional set of intermediate
data structures between the PPTT table/structure and the final arch
specific data structures (which themselves are used to feed other
things, like the scheduler, note the llc parsing). Rather the attempt is
to provide a set of tools to retrieve information and let the policy for
how that information is used be dictated by the consumer.
In the future, if we can further unify the arch specific cpu_topology
structures it would make sense to parse directly into them, but until
that happens I don't think we should try. The existing code does parse
directly into the cache structures, but the cpu topology is subtly arm64
at the moment. If another arch decided to use this, i'm not sure they
would want or need it parsed in exactly the same way.
