Linux 6.10 Goes Ahead In Removing Sysctl Sentinel Bloat

[phoronix]

Phoronix: Linux 6.10 Goes Ahead In Removing Sysctl Sentinel Bloat

Over the past year there's been much work happening within the Linux kernel's sysctl code for clearing up ~64 bytes of bloat per array throughout the kernel by dropping the last sysctl "sentinel" entry at the end of each array. This also helps in reducing the build time of the kernel and is a nice improvement. With Linux 6.10, the sysctl sentinel clearing throughout different subsystems is set to happen...

https://www.phoronix.com/news/Linux-610-Clears-Sentinel-Bloat

[rene]

Finally! Can't want for T2/Linux to run even better on my 40MHz i486 and Sun SPARCstation 2 https://www.youtube.com/watch?v=uu7BK3W4jOE

[Kjell]

Every optimization is highly welcomed

[ultimA]

Finally! Can't want for T2/Linux to run even better on my 40MHz i486 and Sun SPARCstation 2 https://www.youtube.com/watch?v=uu7BK3W4jOE

Sometime Linux runs on microcontroller-class hardware, and there are just barely enough system resources. Saving a few kilobytes can mean a world of difference under such circumstances.

[rene]

Sometime Linux runs on microcontroller-class hardware, and there are just barely enough system resources. Saving a few kilobytes can mean a world of difference under such circumstances.

of course, that's why I'm so thrilled! https://www.youtube.com/watch?v=ch_RTDHCYmo

[npwx]

I would estimate that all the articles about this rather trivial cleanup by far exceed 6272 bytes.

[EphemeralEft]

Sometime Linux runs on microcontroller-class hardware, and there are just barely enough system resources. Saving a few kilobytes can mean a world of difference under such circumstances.

IIRC Linux needs at least a few megabytes to run, so a few kilobytes would be negligible even for tiny devices.

[hkupty]

I'm always impressed by the bold comments in this forum that bear a negative tone towards a positive improvement.
- 64 bytes / array can be significant for some arrays to fit entirely in L1 cache;
- Even if that's not the case, the system is unnecessarily wasting resources;
- Even if that resource is spare and the waste is negligible, it helps reduce build time for the kernel;
- Even if the build is already fast, it is a refactoring that improves code quality.

And if you read attentively the previous post, linked in this article, the Linux Kernel developer (and principal engineer in Samsung) Luis Chamberlain states: "the extra 64-byte penalty is no longer incurred now when we move sysctls out from kernel/sysctl.c to their own files". This means that unbloating `kernel/sysctl.c` now doesn't come with an unnecessary penalty, therefore more code can be moved out, so it has a positive impact in allowing that kind of refactoring.

[caligula]

Every optimization is highly welcomed

But but everyone has at least 7950X3D with 64 GB of RAM these days. M4 got just released. Hard drives are 16 TB or larger. Optimizing software means there's less incentive to develop better hardware.

[caligula]

- Even if the build is already fast, it is a refactoring that improves code quality.

FWIW the build process isn't especially fast. C as a language is one of the core issues here. Replacing pre-processor with hygienic AST macros, using a language optimized for parsing, and replacing tools like gcc+make+ld with a real multi-threaded caching supercompiler would cut down the compilation time by more than two thirds, especially on large systems with lots of cores.