LWN: Comments on "Profile-guided optimization for the kernel"

Profile-guided optimization for the kernel

ndesaulniers — Thu, 10 Sep 2020 17:49:30 +0000

We've reached out to Ian about collaborating on LTO integration; we're in the process of upstreaming LTO patches for LLVM and need help from the GCC side to test and sort out what issues they might run into: https://lore.kernel.org/lkml/CAKwvOdkbkvXdfXLzTNOj8m8_YWj...

For example, LTO has exposed a handful of compiler bugs. Most recently: https://bugs.llvm.org/show_bug.cgi?id=47479.

Profile-guided optimization for the kernel

nivedita76 — Fri, 04 Sep 2020 22:09:40 +0000

Don't know any details, but the LLVM pass sounds similar to gcc's -freorder-blocks-and-partition

In addition to reordering basic blocks in the compiled function, in order to reduce number of taken branches, partitions hot and cold basic blocks into separate sections of the assembly and .o files, to improve paging and cache locality performance.

Profile-guided optimization for the kernel

rbrito — Fri, 04 Sep 2020 05:06:24 +0000

I am eagerly waiting for kernels to be regularly compiled with link-time optimization at least, since the prospects of it generating smaller binaries could help a lot with booting more armv5 machines (the space for the kernel file is limited when loading it with the bootloader).

If the kernel also happens to use fewer bytes in memory, that is a very nice side effect that could be left to userspace in memory constrained machines, so much better. In fact, this would also help with the kernel that phones use (I'm thinking of lineageos here). A leaner kernel would mean less thrashing, which can only be a good thing. I hope that Apps that use NDK can also switch to LTO in the relatively near future.

Having distribution kernels with PGO for regular computers enabled seems to also be very nice. I really, really hope that we're not far from that being the bread-and-butter of kernel compilation.

Also talking about compiler optimizations, in the last few days I read about a new approach that was just merged in (see https://github.com/llvm/llvm-project/commit/94faadac) LLVM called machine function splitter. It seems to be roughly based on the observation that not all hot functions have all their parts hot. It would be lovely to get something similar in GCC.

In fact, if you think about it, many of the optimizations (like reducing the code for little machines like armv5) may also help significantly the code for big, compute-intensive, cloud applications and, so, everyone would benefit from that...