Hacker News Reader

Comment by jeffbee | Hacker News Reader

The part with only 16 cores but 512MB L3 cache ... that must be for some specific workload.

Oracle can charge $40-$100k+ for EE including options per core (times .5)...and some workloads are very cache sensitive. So a high cache, high bandwidth, high frequency, high memory capacity 16 core CPU[1] (x2 socket) might be the best bang for their buck for that million dollar+ license.

[1] https://www.amd.com/en/products/processors/server/epyc/9005-...

Surely that's a good reason for Oracle to increase their prices even more, leading to a cat-and-mouse game between CPU makers and software license sellers.

Hopefully ending when nobody uses Oracle.

Oh yes, this cat-and-mouse game has been going on for more than a decade. But despite that, for any given time and license terms, there is a type of CPU that is optimal for performance/licensing costs, and when the license is as expensive and widely used as it is, it makes sense to sell CPUs for that specific purpose.

It is very Oracle that their license policy gives a reason to make crippled CPUs.

The topology of that part is wild, it's physically the same silicon as the 128-core part but they've disabled all but one core on each compute chiplet. 112 cores are switched off to leave just 16 cores with as much cache as possible.

Inter-core latency will be rough since you'll always be hitting the relatively slow inter-chiplet bus, though.

Does anyone know if modern AMD chips allow mapping the L3 cache and using it as TCM instead of cache? I know older non-X86 processors supported this (and often booted into that mode so that the memory controllers could be brought up), but not sure if it's possible today. If so, that would sure make for some interesting embedded use cases for a large DRAM-less system...

The coreboot docs claim that modern AMD parts no longer support cache-as-RAM.

https://doc.coreboot.org/soc/amd/family17h.html

Lame.

Using it as TCM ram seems super useful.

Although you would need to fight/request it from the OS, so technically I see why they might ditch it.

Wow, thanks for the link, I had no idea:

> AMD has ported early AGESA features to the PSP, which now discovers, enables and trains DRAM. Unlike any other x86 device in coreboot, a Picasso system has DRAM online prior to the first instruction fetch.

Perhaps they saw badly trained RAM as a security flaw? Or maybe doing it with the coprocessor helped them distribute the training code more easily (I heard a rumour once that RAM training algos are heavily patented? Might have imagined it).

If you keep your working set small enough, you should be able to tell the CPU it has RAM attached, but never actually attach any RAM.

It would never flush any cache lines to RAM, and never do any reads from RAM.

Part of me is asking whether some of the 'mitigations' to various things in microcode have necessitated reads from RAM?

Reply on news.ycombinator.com