PPTT handle Handle architecturally unknown cache types
Subsystems (2)
v2 cover PPTT handle Handle architecturally unknown cache types
The ARM Architecture Reference Manual allows for caches to be "invisible" and thus not specified in the system registers under some scenarios such as if the cache cannot be managed by set/way operations.
However, such caches may be specified in the ACPI PPTT table for workload performance/scheduling optimizations.
Currently such caches can cause an error in lscpu -
lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such file or directory
and result in no output, providing a poor user experience. lstopo is also affected as such caches are not included in the output.
Address these issues by attempting to be a little more discerning about when cache information is provided to userspace, and also utilize all sources for cache information when possible.
[v2]
-Updated cacheinfo per Sudeep's suggestion
-Integrated the PPTT fix into existing PPTT code per Sudeep's suggestion
Jeffrey Hugo (2):
drivers: base: cacheinfo: Do not populate sysfs for unknown cache
types
ACPI/PPTT: Handle architecturally unknown cache types
drivers/acpi/pptt.c | 15 +++++++++++---- drivers/base/cacheinfo.c | 2 ++ 2 files changed, 13 insertions(+), 4 deletions(-)
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v2 1/2 drivers: base: cacheinfo: Do not populate sysfs for unknown cache types
If a cache has an unknown type because neither the hardware nor the firmware told us, an entry in the sysfs tree will be made, but the type file will not be present. lscpu depends on the type file being present for every entry, and will error out without printing system information if lscpu cannot open the type file.
Presenting information about a cache without indicating its type is not useful, therefore if we hit a cache with an unknown type, stop populating sysfs so that userspace has the maximum amount of useful information.
This addresses the following lscpu error, which prevents any output.
lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such file or directory
--- drivers/base/cacheinfo.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/base/cacheinfo.c +2 -0
@@ -615,6 +615,8 @@ static int cache_add_dev(unsigned int cpu) this_leaf = this_cpu_ci->info_list + i;if (this_leaf->disable_sysfs)continue ; +if (this_leaf->type ==CACHE_TYPE_NOCACHE ) +break ; cache_groups =cache_get_attribute_groups (this_leaf); ci_dev =cpu_device_create (parent, this_leaf, cache_groups,"index%1u" , i);
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v2 1/2] drivers: base: cacheinfo: Do not populate sysfs for unknown cache types
Hi,
Quoted 26 lines · Jeffrey Hugo
If a cache has an unknown type because neither the hardware nor the firmware told us, an entry in the sysfs tree will be made, but the type file will not be present. lscpu depends on the type file being present for every entry, and will error out without printing system information if lscpu cannot open the type file.
Presenting information about a cache without indicating its type is not useful, therefore if we hit a cache with an unknown type, stop populating sysfs so that userspace has the maximum amount of useful information.
This addresses the following lscpu error, which prevents any output.
lscpu: cannot open/sys/devices/system/cpu/cpu0/cache/index3/type: No such file or directorySuggested-by Sudeep Holla <[email protected]>Signed-off-by Jeffrey Hugo <[email protected]>--- drivers/base/cacheinfo.c | 2 ++ 1 file changed, 2 insertions(+)drivers/base/cacheinfo.c +0
-0
drivers/base/cacheinfo.c static int cache_add_dev(unsigned int cpu) · line 622
Quoted 8 lines
drivers/base/cacheinfo.c +2
-0@@ -615,6 +615,8 @@ static int cache_add_dev(unsigned int cpu) this_leaf = this_cpu_ci->info_list + i;if (this_leaf->disable_sysfs)continue ; +if (this_leaf->type ==CACHE_TYPE_NOCACHE ) +break ; cache_groups =cache_get_attribute_groups (this_leaf); ci_dev =cpu_device_create (parent, this_leaf, cache_groups,"index%1u" , i);
Looks fine to me:
Thanks,
PATCH v2 2/2 ACPI/PPTT: Handle architecturally unknown cache types
In reply to Jeffrey HugoThe type of a cache might not be specified by architectural mechanisms (ie system registers), but its type might be specified in the PPTT. In this case, we should populate the type of the cache, rather than leave it undefined.
This fixes the issue where the cacheinfo driver will not populate sysfs for such caches, resulting in the information missing from utilities like lstopo and lscpu, thus degrading the user experience.
--- drivers/acpi/pptt.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/acpi/pptt.c +11 -4
@@ -402,11 +402,18 @@ static void update_cache_properties(struct cacheinfo *this_leaf, } }/* -* If the above flags are valid, and the cache type is NOCACHE -* update the cache type as well. +* If cache type is NOCACHE, then the cache hasn't been specified +* via other mechanisms. Update the type if either the cache has +* been fully specified in PPTT, or a cache type has been provided. +* +* Note, we assume such caches are unified based on conventional system +* design and known examples. Significant work is required elsewhere to +* fully support data/instruction only type caches which are only +* specified in PPTT. */ -if (this_leaf->type ==CACHE_TYPE_NOCACHE && - valid_flags ==PPTT_CHECKED_ATTRIBUTES ) +if ((this_leaf->type ==CACHE_TYPE_NOCACHE ) && + (valid_flags ==PPTT_CHECKED_ATTRIBUTES || + found_cache->flags &ACPI_PPTT_CACHE_TYPE_VALID )) this_leaf->type =CACHE_TYPE_UNIFIED ; }
Signature · 3 lines
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v2 2/2] ACPI/PPTT: Handle architecturally unknown cache types
Quoted 31 lines · Jeffrey Hugo
The type of a cache might not be specified by architectural mechanisms (ie system registers), but its type might be specified in the PPTT. In this case, we should populate the type of the cache, rather than leave it undefined.
This fixes the issue where the cacheinfo driver will not populate sysfs for such caches, resulting in the information missing from utilities like lstopo and lscpu, thus degrading the user experience.
Fixes 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing)Reported-by Vijaya Kumar K <[email protected]>Signed-off-by Jeffrey Hugo <[email protected]>--- drivers/acpi/pptt.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)drivers/acpi/pptt.c +5
-2@@ -402,11 +402,18 @@ static void update_cache_properties(struct cacheinfo *this_leaf, } }/* -* If the above flags are valid, and the cache type is NOCACHE -* update the cache type as well. +* If cache type is NOCACHE, then the cache hasn't been specified +* via other mechanisms. Update the type if either the cache has +* been fully specified in PPTT, or a cache type has been provided. +* +* Note, we assume such caches are unified based on conventional system
drivers/acpi/pptt.c static void update_cache_properties(struct cacheinfo *this_leaf, · line 417
Quoted 10 lines
drivers/acpi/pptt.c +6
-2+* design and known examples. Significant work is required elsewhere to +* fully support data/instruction only type caches which are only +* specified in PPTT. */ -if (this_leaf->type ==CACHE_TYPE_NOCACHE && - valid_flags ==PPTT_CHECKED_ATTRIBUTES ) +if ((this_leaf->type ==CACHE_TYPE_NOCACHE ) && + (valid_flags ==PPTT_CHECKED_ATTRIBUTES || + found_cache->flags &ACPI_PPTT_CACHE_TYPE_VALID )) this_leaf->type =CACHE_TYPE_UNIFIED ;
I thought I did mention that we can drop the valid_flags altogether unless Jeremy has reasons not to.
Signature · 2 lines
Regards, Sudeep
Re: [PATCH v2 2/2] ACPI/PPTT: Handle architecturally unknown cache types
Quoted 39 lines · Sudeep Holla
Quoted 36 lines · Jeffrey Hugo
The type of a cache might not be specified by architectural mechanisms (ie system registers), but its type might be specified in the PPTT. In this case, we should populate the type of the cache, rather than leave it undefined.
This fixes the issue where the cacheinfo driver will not populate sysfs for such caches, resulting in the information missing from utilities like lstopo and lscpu, thus degrading the user experience.
Fixes 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing)Reported-by Vijaya Kumar K <[email protected]>Signed-off-by Jeffrey Hugo <[email protected]>--- drivers/acpi/pptt.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)drivers/acpi/pptt.c +8
-3@@ -402,11 +402,18 @@ static void update_cache_properties(struct cacheinfo *this_leaf, } }/* -* If the above flags are valid, and the cache type is NOCACHE -* update the cache type as well. +* If cache type is NOCACHE, then the cache hasn't been specified +* via other mechanisms. Update the type if either the cache has +* been fully specified in PPTT, or a cache type has been provided. +* +* Note, we assume such caches are unified based on conventional system +* design and known examples. Significant work is required elsewhere to +* fully support data/instruction only type caches which are only +* specified in PPTT. */ - if (this_leaf->type == CACHE_TYPE_NOCACHE &&
Quoted 9 lines
drivers/acpi/pptt.c static void update_cache_properties(struct cacheinfo *this_leaf, · line 417
Quoted 5 lines
drivers/acpi/pptt.c +3
-1- valid_flags == PPTT_CHECKED_ATTRIBUTES) +if ((this_leaf->type ==CACHE_TYPE_NOCACHE ) && + (valid_flags ==PPTT_CHECKED_ATTRIBUTES || + found_cache->flags &ACPI_PPTT_CACHE_TYPE_VALID )) this_leaf->type =CACHE_TYPE_UNIFIED ;I thought I did mention that we can drop the
valid_flagsaltogether unless Jeremy has reasons not to.
You suggested that perhaps that could be the case. It seemed like an open question to me. I'm at Linaro Connect without access to the device this week, so I guess someone has roughly a week to chime in that the valid flags should be kept, otherwise I'll try a v3 with them removed.
Signature · 4 lines
Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v2 2/2] ACPI/PPTT: Handle architecturally unknown cache types
Hi,
Quoted 53 lines · Jeffrey Hugo
Quoted 42 lines · Sudeep Holla
Quoted 39 lines · Jeffrey Hugo
The type of a cache might not be specified by architectural mechanisms (ie system registers), but its type might be specified in the PPTT. In this case, we should populate the type of the cache, rather than leave it undefined.
This fixes the issue where the cacheinfo driver will not populate sysfs for such caches, resulting in the information missing from utilities like lstopo and lscpu, thus degrading the user experience.
Fixes 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing)Reported-by Vijaya Kumar K <[email protected]>Signed-off-by Jeffrey Hugo <[email protected]>---
drivers/acpi/pptt.c| 15 +++++++++++----1 file changed, 11 insertions(+), 4 deletions(-)drivers/acpi/pptt.c +5
-2@@ -402,11 +402,18 @@ static void update_cache_properties(struct cacheinfo *this_leaf, } } /* -* If the above flags are valid, and the cache type is NOCACHE -* update the cache type as well. +* If cache type is NOCACHE, then the cache hasn't been specified +* via other mechanisms. Update the type if either the cache has +* been fully specified in PPTT, or a cache type has been provided. +* +* Note, we assume such caches are unified based on conventional system
+ * design and known examples. Significant work is required elsewhere to
+ * fully support data/instruction only type caches which are only + * specified in PPTT.
*/
- if (this_leaf->type==CACHE_TYPE_NOCACHE&&Quoted 9 lines
Quoted 5 lines
-
valid_flags==PPTT_CHECKED_ATTRIBUTES)
+ if ((this_leaf->type==CACHE_TYPE_NOCACHE) && + (valid_flags==PPTT_CHECKED_ATTRIBUTES|| +found_cache->flags&ACPI_PPTT_CACHE_TYPE_VALID))this_leaf->type=CACHE_TYPE_UNIFIED;I thought I did mention that we can drop the
valid_flagsaltogether unless Jeremy has reasons not to.
Quoted 2 lines
You suggested that perhaps that could be the case. It seemed like an open question to me. I'm at Linaro Connect without access to the device this week, so I guess someone has roughly a week to chime in that the valid flags should be kept, otherwise I'll try a v3 with them removed.
The point of the valid_flags/CHECKED_ATTRIBUTE was to help assure that a minimum set of attributes were being provided by the firmware. If we are going to reset the CACHE_TYPE, then we might as well remove the valid_flag/CHECKED_ATTRIBUTE counts as it can be easily bypassed.
So, yes please, remove the valid_flags with this change.
Thanks,