Hacker News new | past | comments | ask | show | jobs | submit login

> with their 128 kB data cache

Bigger than that. (https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64...)

/* I-Cache, 256KB for Firestorm, 128KB for Icestorm, 6-way. /

/ D-Cache, 160KB for Firestorm, 8-way. 64KB for Icestorm, 6-way. */

Apple also uses a base 16KB page size on macOS, with 4KB being present for backwards compatibility (x86_64 apps) and the wider ecosystem (running Windows for example).

> Maybe they've gone with some special purpose hardware support for emulating x86 4k pages on their 16k page architecture

Nah, it's that when you run an x86 process, one of the TTBRs is pointed to a page size corresponding to 4KB pages.




Firestorm L1 d$ is 128kB most diagrams and documentation will show that. This latency measurement pretty well confirms it too -

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

Apple definitely takes advantage of VI=PI for their caches.

160kB is not a good size for a cache, surely must be a typo.

i$ has more options for handling aliases. You don't actually even need to eliminate them at all because it's a read-only cache. So it's not unusual to see these caches exceed the VI=PI geometry.


That’s what Apple explicitly says. Why they don’t match with measurements is another matter… (and no, it’s not a typo)

ECC? Needs hugepages? Or hardware erratum? I don’t know for sure.

Also, at least from the VM perspective icache is reported as PIPT, which is not too surprising but still worth noting.


> That’s what Apple explicitly says. Why they don’t match with measurements is another matter… (and no, it’s not a typo)

Ridiculous. You're just making things up. It clearly doesn't have a 160kB 6-way L1 dcache. Nor are the small cores 64kB 6-way -- those don't even divide that's ridiculous. Why do you say it's not a typo?

They "explicitly" say it is 160kB in that backwater code comment. They also explicitly say it's 128kB in this presentation https://www.youtube.com/watch?v=5AwdkGKmZ0I&t=534s so what makes your source the authoritative one?? Pretty obviously it's a quick cut and paste job with a typo (two in one line actually) in it.

> ECC? Needs hugepages? Or hardware erratum? I don’t know for sure.

ECC? Erratum? Come on. It's clearly because it's 128kB.


I actually asked and got told that it’s not a typo. But not more details beyond that so I can only speculate…

And yeah, 192KB/128KB is what the HW behaves as by all accounts by measurements, making this even more odd…


Okay so it was deliberately written by someone who was misinformed about at least two properties of the caches then, both size and associativity.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: