Linux Parallel CPU Bring-Up Shows Great Impact Bringing Up 1,920 Sapphire Rapids Cores

After the prior kernel patches had stalled in their review process, last week work was revived on x86_64 parallel CPU bring-up for the Linux kernel to help in booting the kernel faster on larger core count desktops and servers. The results have been promising and over the past few days more test results have flowed in along with other positive commentary that will hopefully this time lead to the work ultimately getting upstreamed.

There's been much interest from users and commentary from upstream developers over the latest "v6" round of patches for this parallel CPU bring-up for x86_64 processors. Hopefully this time it won't fizzle out like it had for over a year with the prior patches. But as noted in last week's article, for now AMD processors are opting out of this parallel bring-up optimization due to issues affecting some older CPUs. Hopefully though the AMD support will get sorted out since with AMD Threadripper and EPYC having even higher core counts than Intel's current processors, they stand to benefit a great deal.

In addition to a lot of technical discussions over the patches in the past few days, one of the interesting posts on Sunday was from HPE testing the parallel bring-up support using 1,920 cores from Intel 4th Gen Xeon Scalable "Sapphire Rapids". Using a sixteen CPU socket configuration with 60-core Sapphire Rapids CPUs with Hyper Threading enabled, the x86_64 parallel CPU bring-up Linux kernel patches were tested.

For the nearly two thousand logical Sapphire Rapids cores, the tentative patches had a big impact: the Linux kernel took 71 seconds originally to start all the CPUs while with the parallel bring-up patches it dropped to just 14 seconds.

The commentary from HPE was "That is impressive." going from 71 to 14 seconds with this single patch series. Or for getting a full boot of this 16 socket Sapphire Rapids configuration was 223 seconds by default and then reduced by 57 seconds with the patches.

The parallel bring-up patches have the potential to provide big savings for the kernel boot time, granted, on such a configuration the DDR5 memory initialization/training times likely take much more time for the system to POST, etc. If Kexec'ing kernels and other scenarios there would be less downtime, but of course during system downtime every second counts. Hopefully the patch series manages to get worked into good shape this year and reaches the mainline Linux kernel with CPU core counts only going higher.