Linux Kernel Patches Allow Booting Higher Core Count Systems Much Faster

[phoronix]

Phoronix: Linux Kernel Patches Allow Booting Higher Core Count Systems Much Faster

Patches started earlier this year for allowing the parallel bring-up of secondary CPU cores for x86_64 processors have gotten back to being worked on and were sent out on Thursday for review...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-x86_64-Parallel-CPU-Boot

[GruenSein]

This is nice and all but a factor of 15 (or above) times almost nothing is still almost nothing. Most applications also don't require constant reboots. I am wondering about the motivation behind this work. Nonetheless, it is nice to have, I guess.

[lacek]

This is nice and all but a factor of 15 (or above) times almost nothing is still almost nothing. Most applications also don't require constant reboots. I am wondering about the motivation behind this work. Nonetheless, it is nice to have, I guess.

This is a short sighted perspective:
- number of cores is expected to grow, so "normal people" computers will not be 4-8 cores anymore, servers are already in 128-256 range, expected to grow
- this will be useful in de-hybernation as well
- this is just one element of the puzzle, this is how actual progress occurs: not my major, possibly buggy, yearly rewrites but by tiny incremental improvements. Major rewrites occur typically only after someone has a great idea, or if it becomes obvious that code needs restructuring, not tinkering.

Actually the patch note suggests that 500ms -> 34ms speedup follows from some patches in February, and this is just a follow up.

[Jabberwocky]

I'm guessing this is to reduce autoscaling latency. There are other advantages too of course.

[geearf]

This is nice and all but a factor of 15 (or above) times almost nothing is still almost nothing. Most applications also don't require constant reboots. I am wondering about the motivation behind this work. Nonetheless, it is nice to have, I guess.

It could be quite nice for servers.
Sometimes you need to reboot them (crashes, updates, replacement, etc), so saving time can be useful.
If you have a big enough farm with enough cores, at some point the time saved could be equivalent to having an extra server or more.
But even without that, sometimes you have barely more than the processing you need, when you need to catch up every little bit saved can help you going back to realtime ASAP.
And of course, as said before this is just part of the whole puzzle, it'll all add up eventually to a decent saving.

[GruenSein]

This is a short sighted perspective:
- number of cores is expected to grow, so "normal people" computers will not be 4-8 cores anymore, servers are already in 128-256 range, expected to grow
- this will be useful in de-hybernation as well
- this is just one element of the puzzle, this is how actual progress occurs: not my major, possibly buggy, yearly rewrites but by tiny incremental improvements. Major rewrites occur typically only after someone has a great idea, or if it becomes obvious that code needs restructuring, not tinkering.

Actually the patch note suggests that 500ms -> 34ms speedup follows from some patches in February, and this is just a follow up.

First of all, I am not saying that this patch is "worthless" or anything. Also, I am perfectly aware of growing core counts. Nonetheless, we are seeing sub-second durations of a relatively rare process (booting) using the highest core count systems, which are affected most. I am merely pointing out that even an infinite performance improvement, i.e., 0ms instead of 500ms during boot time, is still just a 500ms saving even though infinity sounds like a lot. I also did not say anything about rewrites or such. Settle down, please.

It could be quite nice for servers.
Sometimes you need to reboot them (crashes, updates, replacement, etc), so saving time can be useful.
If you have a big enough farm with enough cores, at some point the time saved could be equivalent to having an extra server or more.
But even without that, sometimes you have barely more than the processing you need, when you need to catch up every little bit saved can help you going back to realtime ASAP.
And of course, as said before this is just part of the whole puzzle, it'll all add up eventually to a decent saving.

Just to play devil's advocate here: A year has 8760h, which is equal to roughly 31.5M seconds. To make up the equivalent usage of a single node, this is the amount of boot time that has to be saved. If we consider the worst case of 500ms and even assume this time can be optimized to essentially zero, we'd have to reboot 63 million times per year for this patch to make up the capacity of a single node. Even if we were to assume a huge farm of 100 000 nodes (not cores. nodes!), this comes down to two reboots every single day on every single node. If that is the case, reducing the number of crashes, updates etc. seems a lot more promising. This is why I am wondering what exactly motivated this work, which I maintain is a fair question. Possibly someone simply stumbled across this optimization while doing other stuff and thought "Why the hell not?", which is also perfectly legitimate.

So let me reiterate: This is a nice patch and optimizations are always welcome. I just take issue with the fact this is presented as a huge perfomance increase because it is only a huge increase in relative terms starting from a basically negligible computation time to begin with.

[geearf]

So let me reiterate: This is a nice patch and optimizations are always welcome. I just take issue with the fact this is presented as a huge perfomance increase because it is only a huge increase in relative terms starting from a basically negligible computation time to begin with.

Fair enough!

[cl333r]

So if I have a Core i5 with 6 cores how much faster will it boot? 2ms?

[dlq84]

It could be quite nice for servers.
Sometimes you need to reboot them (crashes, updates, replacement, etc), so saving time can be useful.
If you have a big enough farm with enough cores, at some point the time saved could be equivalent to having an extra server or more.
But even without that, sometimes you have barely more than the processing you need, when you need to catch up every little bit saved can help you going back to realtime ASAP.
And of course, as said before this is just part of the whole puzzle, it'll all add up eventually to a decent saving.

My experience is kernel boot time is negligible compared to POST time. POST can take a minute or two, so 1 second doesn't matter. Still. I don't complain about any performance improvements.

[geearf]

My experience is kernel boot time is negligible compared to POST time. POST can take a minute or two, so 1 second doesn't matter. Still. I don't complain about any performance improvements.

Very true, since I moved to a Ryzen system POST is horrible!
I can only hope servers don't have that problem.