Revert arm64 cache geometry
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] Revert arm64 cache geometry
Quoted 7 lines
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Ard Biesheuvel
Fair enough. It is a bit disappointing that we cannot trust these values, but if the architecture does not mandate their accuracy, we obviously should not be using them in the way that we are.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
I think we have similar code in the ARM tree, so we should probably make some changes there as well.
I've opposed exporting the cache dimensions to userspace for several reasons:
I agree with the arguments below. However, what I refer to here is kernel code that infers whether a certain VIPT cache is non-aliasing based on the way size, which is calculated from values that are exposed to software for the sole purpose of enumerating cachelines by set/way.
No, CCSIDR_EL1 is for the sole purpose of indicating how to clean / invalidate
caches by set and way. The documentation explicitly says it is not for
enumerating the cache geometry.
________________________________________
From: Ard Biesheuvel <[email protected]>
Sent: Thursday, October 29, 2015 9:28 AM
To: Russell King - ARM Linux
Cc: Alexander Van Brunt; linux-arm-kernel at lists.infradead.org; Will Deacon; Sudeep Holla; Catalin Marinas
Subject: Re: [PATCH 0/3] Revert arm64 cache geometry
Quoted 7 lines · Russell King - ARM Linux
Quoted 6 lines · Ard Biesheuvel
Fair enough. It is a bit disappointing that we cannot trust these values, but if the architecture does not mandate their accuracy, we obviously should not be using them in the way that we are.
Quoted 6 lines
Quoted 2 lines
I think we have similar code in the ARM tree, so we should probably make some changes there as well.
I've opposed exporting the cache dimensions to userspace for several reasons:
I agree with the arguments below. However, what I refer to here is kernel code that infers whether a certain VIPT cache is non-aliasing based on the way size, which is calculated from values that are exposed to software for the sole purpose of enumerating cachelines by set/way.
Quoted 34 lines
* it will become a nightmare with the various different register formats to properly decode these values
* older CPUs don't have the cache ID registers, so we'd need to augment any export with additional static configuration somehow
* I don't trust userland with this information to make the right choices, especially when faced with further levels of caches.The main reason for people wanting the cache dimensions has been "so we can select the optimal code for the CPU". Given all the combinations of caches out there, I've always said selecting code based on one level of cache is totally insane, and userspace is better off doing some performance measurement of its implementations and selecting the most appropriate version.
There's many things that affect the performance of code paths with CPUs. It's not just about cache line size, but instruction latencies, write delays, branch prediction and so forth. You can't _say_ "because this CPU has a 32K L1 cache, if I optimise my code as X it'll perform better everywhere with a 32K L1 cache than optimised Y."
Selecting code based on cache parameters is just wrong.
There may be cases where userspace would like to know the cache line size, so it can appropriately align data structures - but that again depends on what you're trying to achieve, and what if the L1 cache line size is different from the L2 cache line size...
It's a minefield, one which IMHO userspace shouldn't be trusted with. Userspace should assume the worst case cache line size seen in ARM CPUs and be done with it.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.