Fast Kernel Headers Work Restarted For Linux To Ultimately Speed Up Build Times

[Keats]

I must be missing something

Everything important, as usual.

[darkbasic]

you're going to clock somewhere between 10-15 minutes, and packaging overhead to make your build redistributable would add another 3 or so minutes.

You hugely underestimated packaging overhead: Arch Linux's kernel packages build in 36 minutes on my AMD Ryzen 9 PRO 7940HS.

[fallingcats]

You hugely underestimated packaging overhead: Arch Linux's kernel packages build in 36 minutes on my AMD Ryzen 9 PRO 7940HS.

What? Arch Linux' packageing overhead nowadays is whatever time zstd takes to compress. That's it, the rest is build time. I very much doubt it's more than 30s tbh.

[darkbasic]

What? Arch Linux' packageing overhead nowadays is whatever time zstd takes to compress. That's it, the rest is build time. I very much doubt it's more than 30s tbh.

zstd compression has been disabled on my system because I have compression at the filesystem level in zfs. For sure docs take plenty of time and are part of the kernel packages, otherwise I have no idea why it takes so long.

[fallingcats]

zstd compression has been disabled on my system because I have compression at the filesystem level in zfs. For sure docs take plenty of time and are part of the kernel packages, otherwise I have no idea why it takes so long.

Okay, you've unsettled me. Brb testing it now.

[sophisticles]

Everything important, as usual.

Thanks for the technical explanation.

[hkupty]

Bottom line is that no one should ever do "make allmodconfig", they should do "make tinyconfig" and then have a desktop app that allows the end user to install the relevant modules for their hardware,

- CI/CD pipelines should run `make allmodconfig` anyway;
- Even for the `make tinyconfig` case, the speedup should be beneficial;
- Improving the headers not only improves compilation, but also static analysis, linter, etc, speeding up development time;
- A recurring issue is the fact that some patches are either not compiling or has obvious flaws, so improving on this area can also impact positively on reducing the bounces back-and-forth a patch goes through before being accepted;
- Having a better project structure also allows for better onboarding, reducing the cognitive load when refactoring and reduces the risk of conflicts (before or after merge);
- And last but not least, Linux is an open project where people can voluntarily chose to work on certain features for whatever reason. Why is what they're doing with their time causing this much backlash?

[sophisticles]

- And last but not least, Linux is an open project where people can voluntarily chose to work on certain features for whatever reason. Why is what they're doing with their time causing this much backlash?

It's not so much backlash, it's that if they really want to speed up code compilation, there are much better approaches than what they are doing.

Want to do something good that will significantly speed up compilation?

How about work on adopting this to C:

https://github.com/Snektron/pareas

Think how great it would be if someone took this work and created a super fast C compiler that can leverage the massive parallelism available with GPUs.

That's what they should be working on.

[smitty3268]

- And last but not least, Linux is an open project where people can voluntarily chose to work on certain features for whatever reason. Why is what they're doing with their time causing this much backlash?

It's one person trolling as usual. Not a huge amount of backlash, just typical phoronix.

[darkoverlordofdata]

One year I was ride sharing with another employee who was a build engineer for Vista. He told me that with a bunch of hardware upgrades, we managed to improve the build time for NT from 7 days down to 3 days. Proud, he was.