4 ms·

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/

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-deep-dive/2 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.

my123 4y ago
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.
- throwawaylinux 4y ago
  > 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 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.
  - my123 4y ago
    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…
    - throwawaylinux 4y ago
      Okay so it was deliberately written by someone who was misinformed about at least two properties of the caches then, both size and associativity.

my123 4y ago

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.

throwawaylinux 4y ago
> 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 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.
- my123 4y ago
  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…
  - throwawaylinux 4y ago
    Okay so it was deliberately written by someone who was misinformed about at least two properties of the caches then, both size and associativity.