lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ