Re: [PATCH v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag

[Jeremy Linton <jeremy.linton@arm.com>]

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.