[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <OSBPR01MB2037CAAFECABB5B1C35B0ED080199@OSBPR01MB2037.jpnprd01.prod.outlook.com>
Date: Thu, 8 Jul 2021 01:59:42 +0000
From: "tarumizu.kohei@...itsu.com" <tarumizu.kohei@...itsu.com>
To: 'James Morse' <james.morse@....com>,
"'linux-arm-kernel@...ts.infradead.org'"
<linux-arm-kernel@...ts.infradead.org>
CC: "'hpa@...or.com'" <hpa@...or.com>,
"'tglx@...utronix.de'" <tglx@...utronix.de>,
"'mingo@...hat.com'" <mingo@...hat.com>,
"'x86@...nel.org'" <x86@...nel.org>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
"'Will@...nel.org'" <will@...nel.org>,
'Catalin Marinas' <catalin.marinas@....com>,
'Borislav Petkov' <bp@...en8.de>
Subject: RE: [RFC] Adding A64FX hardware prefetch sysfs interface
Hi, ARM folks.
> For that we already have a hierarchy:
>
> tree /sys/devices/system/cpu/cpu0/cache/
> /sys/devices/system/cpu/cpu0/cache/
> ├── index0
> │ ├── coherency_line_size
> │ ├── id
> │ ├── level
> │ ├── number_of_sets
> │ ├── physical_line_partition
> │ ├── shared_cpu_list
> │ ├── shared_cpu_map
> │ ├── size
> │ ├── type
> │ ├── uevent
> │ └── ways_of_associativity
> ├── index1
> │ ├── coherency_line_size
> │ ├── id
> │ ├── level
> │ ├── number_of_sets
> ...
>
> that's cpu<NUM>/cache/ and I believe ARM shares some of that code too.
>
> > l1_enable : This sets or displays whether hardware prefetch is enabled for L1 cache.
> > l2_enable : This sets or displays whether hardware prefetch is enabled for L2 cache.
> > l1_dist : This sets or displays whether hardware prefetch distance for L1 cache.
> > l2_dist : This sets or displays whether hardware prefetch distance for L2 cache.
> > l1_reliable : This sets or displays whether reliableness attribute for prefetch access for L1 cache.
> > l2_reliable : This sets or displays whether reliableness attribute for prefetch access for L2 cache.
>
> Right, that I'd design differently:
>
> .../cache/prefetcher/l1/
> /l1/enable
> /l1/dist
> /l1/reliable
> ... /l2/
> ... /l3/
>
> so that you have a directory per cache level and in that directory you
> have each file.
>
> But let's loop in ARM folks as this is an ARM CPU after all and they'd
> care for that code.
Could you comment on the following two ideas for the sysfs interface directory structure to control hardware prefetch?
1. /sys/devices/system/cpu/cpu<num>/cache/prefetcher
2. /sys/devices/system/cpu/cpu<num>/prefetcher
We think that the Proposal 1 is better because it will be clear that it is a cache-related feature.
> To the ARM folks:
> Would you give me information about the current state of cpu<num>/cache implementation in ARM and the future plans?
> If it doesn't yet exist as a feature, we would like to contribute to the work to enable it.
About the above question, we thought the cpu<num>/cache directory(/sys/devices/system/cpu/cpu<num>/cache) is not yet implemented on ARM64 in the first place.
Because the cpu<num>/cache directory does not exist on our ARM64 machine, FX700 with the A64FX processor.
However, we realized that even for ARM64, the cpu<num>/cache directory is created if "ACPI PPTT" or "devicetree" is supported.
This problem was caused by the FX700 firmware not supporting "ACPI PPTT" and was not a common problem with the ARM64.
Therefore, we withdraw the above question.
On the other hand, for the new sysfs interface to control hardware prefetch, we’d like to consider an environment that does not support "ACPI PPTT".
If we adopt Proposal 2, no special consideration is required.
However, if we adopt Proposal 1, it is necessary to consider, for example, creating an empty cpu<num>/cache directory in the environment that does not suport "ACPI PPTT".
We don't think to create empty directory is problem, because the hardware prefetch control sysfs interface does not depend on the contents of cpu<num>/cache/index<num>.
If we create an empty directory, are there any other issues to consider?
Best regards,
Kohei Tarumizu
Powered by blists - more mailing lists