Linux 6.3 EDAC Prepares For Intel Granite Rapids With Up To 12 DDR5 Memory Channels

Intel open-source engineers continue to be quite busy in bringing up the Linux support for Emerald Rapids as the successor to Sapphire Rapids and then as well for Granite Rapids as the Xeon Scalable processors following that. With the i10nm EDAC changes queued up ahead of Linux 6.3, there is support through Granite Rapids as well as confirming Granite Rapids supporting up to 12 channel DDR5 system memory.

Queued up this week into RAS.git's "edac-for-next" Git branch ahead of the Linux 6.3 merge window in February is the Emerald Rapids and Granite Rapids support within i10nm, the error detection and correction driver used by Xeon server CPUs since Ice Lake for memory controller error reporting.

The Emerald Rapids support in the Intel EDAC driver is just a one-line addition adding the necessary ID. That's not too surprising with all indications being that Emerald Rapids is very close to Sapphire Rapids in terms of features/capabilities. Other Emerald Rapids additions in Linux 6.2 have generally been just adding in new IDs too and otherwise following the same driver code paths as Sapphire Rapids.

With the Granite Rapids addition for i10nm EDAC is where things get a bit more interesting. For the Granite Rapids support it notes of different memory controller counts between different Granite Rapids CPUs, different MMIO offsets, and other differences compared to Sapphire/Emerald Rapids. So with the EDAC driver it now detects the number of present memory controllers at run-time due to the varying number of memory controllers in different Granite Rapids CPU models.

With this new Intel EDAC code, it confirms Granite Rapids will support up to 12 memory channels (not more than 12 as another check in the driver code now errors out if exceeding a constant set to 12). The static number of memory channels set though for Granite Rapids is set to 12 prior to dynamically determining the actual count at run-time.

There have been some rumors indicating twelve channel DDR5-6400 support with Granite Rapids while others reporting eight channels, but in any case with this open-source driver code being merged in Linux 6.3 it confirms that there will be up to 12 memory channels with Granite Rapids. (No changes with Emerald Rapids over Sapphire Rapids.) With Xeon Scalable processors up to this point they have all included support for the same number of memory channels across the product stack, but with lower SKUs being capped to running at lower memory speeds.

Now looking ahead to Granite Rapids, not only may SKUs be differentiated on the system memory side by the DDR5 memory speed but also the number of memory controllers/channels supported for a given processor. With Sapphire Rapids tiled layout there are four tiles with one memory controller and two DDR5 channels per tile, but presumably with Granite Rapids is where we'll see more -- and varying number of -- tiles based on the SKU, thus the possibility of different memory channel counts.

The i10nm EDAC work also confirms that there will still be Granite Rapids SKUs with HBM2 memory expected, which is good to see.

With the recently launched 4th Gen EPYC "Genoa" processors is where AMD introduced 12 channel DDR5-4800 memory support across their entire product line-up. In case you missed it, see my AMD EPYC Genoa 6 / 8 / 10 / 12 memory channel scaling comparison with many reference benchmarks there for the benefits of 12 channel DDR5 server memory.

As usual, kudos to Intel open-source engineers for already working on getting the Granite Rapids / Emerald Rapids driver support changes upstreamed well in advance of the product launches. This continues to be one of the strong areas for Intel is generally getting much of their Linux enablement carried out well in advance of launch, including for areas like GCC and LLVM/Clang compiler support where too they have already started on upstreaming their patches.