Hacker News Reader

Comment by anonymous908213 | Hacker News Reader

> Don’t pass around data of size 4046-4080 bytes or 8161-8176 bytes, by value (at least not on an AMD Ryzen 3900X).

What a fascinating CPU bug. I am quite curious as to how that came to pass.

That's called 4k aliasing. 4K aliasing occurs when you store one memory location, then load from another memory location which is 4KB offset from original.

(and if it is not apparent to some readers, most modern x86-based systems use 64 byte cache line sizes, which is sort of analogous to disk block size - quite a few memory operations tend to happen in 64 byte chunks under the covers - the ones that don't are "special")

To my knowledge all x86 based systems and ARM and Qualcomm designed chips all use 64 byte cache lines.

Apple's M2 uses 128-byte cache line.

Apparently these ~4k spikes are showing up only on AMD, and not on Intel, which is the one known to suffer from the 4k aliasing problem.

I wonder if it has to do with a non-ideal implementation of virtual address resolution for the next page.

Would you expect different performance with 2M page sizes? Is this a TLB issue or just a fundamental hardware issue?

Me too, and I hope this article gets more traction.

Apparently some sizes are cursed!

It would be great to repeat the author’s tests on other CPU models

I wonder what the page size is on his system (and what effective alignment his pointers have). If it's 4K, the sizes look really close to 0x1000 and 0x2000 - maybe crossing page boundaries?

It's because of cache addressing conflicts. If two addresses have the same cache key your cache suddenly doesn't work anymore. And many CPUs just use the low bits instead of hashing it.

L1 caches are usually N-way associative, so that should only become a consistent problem if you access N distinct addresses with the same key (in this case the same offset (with likely 64-byte granularity) relative to a 4K boundary).

Reply on news.ycombinator.com