Parallel CPU Bring-Up Poised For Linux 6.5

[phoronix]

Phoronix: Parallel CPU Bring-Up Poised For Linux 6.5

Months in the making have been the patches for x86_64 parallel CPU boot support to allow secondary CPU cores to be booted in parallel for shortening Linux kernel boot times. Over time the Linux parallel CPU bring-up patches have gone through many revisions while it looks like this work is now positioned for introduction with the Linux 6.5 kernel later this summer...

https://www.phoronix.com/news/Parallel-CPU-Bringup-TIP-Linux

[Joe2021]

Would be very interesting to see the difference for mediocre core counts (8-32)...

[farnz]

Would be very interesting to see the difference for mediocre core counts (8-32)...

I wouldn't expect huge improvements - the numbers from the V2 cover letter https://lore.kernel.org/lkml/2023050...linutronix.de/ say that you gain anything from 0.35 to 3.5 ms per CPU thread for bring-up time, and up to 8 ms per CPU core for microcode updates.

So at 8 cores, you could gain as little as 2.8 ms (no SMT/Hyperthreading, fast CPU bring-up, no microcode update), or as much as 70 ms (16 threads, big microcode update). Moving to 32 cores could gain you as little as 11 ms, or as much as 280 ms, depending on the system.

[stiiixy]

I think I counted 'bring up' seven times in this article. Is not 'enablement', 'facilitate' or 'implement' more appropriate?

What does bring up code mean.

[Jaxad0127]

I think I counted 'bring up' seven times in this article. Is not 'enablement', 'facilitate' or 'implement' more appropriate?

What does bring up code mean.

"Bring up" refers to CPU initialization and related processes (like microcode loading). "parallel CPU boot support to allow secondary CPU cores to be booted in parallel"

Bring-up is the term used in the code (the commit log in the second image uses it several times).

[ssokolow]

Moving to 32 cores could gain you as little as 11 ms, or as much as 280 ms, depending on the system.

To be fair, that worst-case 280ms figure isn't trivial if you're trying to achieve 2-second boots and your Intel CPU has a lot of microcode fingers in its Spectre/Meltdown dike.

[Paradigm Shifter]

And this will mean practically nothing if various controller boots, AGESA etc. are still in the minute-plus range. It's truly insane watching the pre-POST spew on our Epyc server. It goes on. And on. And on. And on. And eventually, the classic BIOS screen appears and tells me what CPU I have and how much RAM is installed, before handing over to a RAID controller which then slowly walks its way through loading its firmware, checking drives and sitting on an "everything is happy" bit of feedback for a few seconds before handing back to the main BIOS, which then checks everything again and then, finally, boots the OS. And that server doesn't even have any of the really high-core-count CPUs. The Intel boxes are better, but still slow due to the RAID controller.

For fun, I ran a test: does that server boot faster than I can walk back from the server room to my office? From a cold boot, I can do the three minute walk from [building server room is in] to [building my office is in], sit at my desk and ssh is still unresponsive. I guess the next test would be "can I make a filter coffee faster than the server boots?"

[kobblestown]

From a cold boot, I can do the three minute walk from [building server room is in] to [building my office is in], sit at my desk and ssh is still unresponsive.)

Eeer, doesn't your server have BMC? Why do you have to walk there to boot it?

Not that's there's anything wrong with walking, but just sayin..

[stiiixy]

And this will mean practically nothing if various controller boots, AGESA etc. are still in the minute-plus range. It's truly insane watching the pre-POST spew on our Epyc server. It goes on. And on. And on. And on. And eventually, the classic BIOS screen appears and tells me what CPU I have and how much RAM is installed, before handing over to a RAID controller which then slowly walks its way through loading its firmware, checking drives and sitting on an "everything is happy" bit of feedback for a few seconds before handing back to the main BIOS, which then checks everything again and then, finally, boots the OS. And that server doesn't even have any of the really high-core-count CPUs. The Intel boxes are better, but still slow due to the RAID controller.

For fun, I ran a test: does that server boot faster than I can walk back from the server room to my office? From a cold boot, I can do the three minute walk from [building server room is in] to [building my office is in], sit at my desk and ssh is still unresponsive. I guess the next test would be "can I make a filter coffee faster than the server boots?"

Flat white.

But proper silky milk, no roadhouse bubbles!

Good question above, why you walking to the server room? Sometimes, it's nice to touch the equipmemt, eh?

[stiiixy]

"Bring up" refers to CPU initialization and related processes (like microcode loading). "parallel CPU boot support to allow secondary CPU cores to be booted in parallel"

Bring-up is the term used in the code (the commit log in the second image uses it several times).

Bring up sounds like something you do after mixing drinks at a party