--- (---.delete@this.redheron.com) on September 11, 2021 9:53 am wrote:

> What I have not established is any particular claim as to how Apple does it in the L1D, just
> that whatever they do, they manage to hide it from visible code. Standard partial tag comparison
> is a probabilistic thing so it should occasionally fail and generate a timing glitch. I never
> saw such -- but Apple have a very nice, lightweight, Replay+Speculative Scheduling mechanism,
> so with rare enough glitches, they can probably hide such a glitch.


It's pure math, for small L1 8-way associative cache not so much address range is needed for practical perfect hit rates. We do know that AMD does use 8 tag bits, so 20 bit address range for 32KB L1 data cache with simple xor hashed information from next 8 address bits mixed in to alter aliasing addresses. It was being able to reverse engineer with software that scans aliasing patterns - but with normal code that kind of addressing newer gives any kind of performance degradation.

>
> Compare this to throughput based on address patterns, where you can, with carefully crafted patterns,
> very definitely see the falloff in throughput with different TLB access requirements, requests that all
> route to one half of the cache, requests separated by varying numbers of cache lines, and so on.

Is there to be find TLB-trashing degradation in performance. It should be simple to test, fill L1 lines from different pages with offset go beyond way set limitations and performance should degrade after L1 TLB coverage ends. So far I only have seen Anandtech testing it, and so far it seems that TLB trashing for moderns CPU's like Zen and Apple devices start right after L1, so L1 doesn't suffer TLB limitation -> L1 is purely virtually accessed.