AMD CPU Microcode Will Be Getting Larger With Future Processors

[phoronix]

Phoronix: AMD CPU Microcode Will Be Getting Larger With Future Processors

Future AMD CPUs will be having larger microcode patches and thus the Linux kernel is now being adapted to better handle that increased microcode payload...

https://www.phoronix.com/news/Larger-AMD-CPU-Microcode

[colejohnson66]

Maybe I'm missing something, but why is there even a size limit in the first place? Just hand off the address and size of the blob to the CPU (as normal), and let it decide if the blob is too big. And it should never be too big because the blobs are linked by processor revision information. The fact that the limit was raised beyond the new limit also makes clear that the kernel doesn't need to care.

[GreenReaper]

Maybe I'm missing something, but why is there even a size limit in the first place?

Because the kernel allocates a static buffer to handle the microcode based on the number of NUMA nodes. The result is using 32MB rather than 12MB on what looks to be a MAXSMP-capable configuration (2^10 = 1024 nodes, 1024 × 4096 × 8 = 32MB).

This is one reason you might want to compile your own kernel, either to limit the number of nodes or remove microcode support entirely.

[curfew]

This is one reason you might want to compile your own kernel, either to limit the number of nodes or remove microcode support entirely.

This is the most rétärdèd thing I've encountered on this forum. Suggestion to compile your own kernel so as to save 32 MB of RAM by disabling a critical feature. (On a system that is meant for massively parallel processing i.e. will come with dozens of gigabytes oh memory.)

[schmidtbag]

Really gets me to wonder why so much microcode is necessary in the first place.

[GreenReaper]

Sure, on such a system that would be silly, however this is a distro kernel, openSUSE Tumbleweed, so the cost will be incurred by users of this kernel on this platform. This option is also set in Debian kernels.

[emansom]

Needs the space for NSA kernel and userspace utils.

[CHECK_12345]

I compile my own debloated kernel with all things built-in (no modules, no initrd) with microcode disabled and it boots fast compared to the stock kernel the distro gives

[nvaert1986]

This is the most rétärdèd thing I've encountered on this forum. Suggestion to compile your own kernel so as to save 32 MB of RAM by disabling a critical feature. (On a system that is meant for massively parallel processing i.e. will come with dozens of gigabytes oh memory.)

I fail to see how this is a bad thing and you're not aware of his particular situation. There's a lot of different use cases and on an embedded system that's not connected to the internet and has memory constraints this could actually be a viable option.

I compile my own custom kernels too
- To save RAM (though disabling features you need is not a good idea of course as per your suggestion)
- To save space on my boot partition where the kernel resides
- To not have to use a initramfs for quicker boot times
- To tweak and tune the performance of my kernel for my specific use case on that specific system
- To have a more secure system by customizing my configuration (hardening) and limiting the options that I compile into my kernel or even compile as module.

[yoshi314]

This is the most rétärdèd thing I've encountered on this forum. Suggestion to compile your own kernel so as to save 32 MB of RAM by disabling a critical feature. (On a system that is meant for massively parallel processing i.e. will come with dozens of gigabytes oh memory.)

what if it's not for a system that is not meant for massively parallel processing?