Re: [PATCH 6/6] Add Propeller configuration for kernel build.

[Nathan Chancellor <nathan@kernel.org>]

On Fri, Sep 27, 2024 at 03:45:39PM -0700, Nick Desaulniers wrote:
> On Thu, Sep 19, 2024 at 4:52 AM Maksim Panchenko <max4bolt@gmail.com> wrote:
> >
> > On Sun, Jul 28, 2024 at 01:29:56PM -0700, Rong Xu wrote:
> > > Add the build support for using Clang's Propeller optimizer. Like
> > > AutoFDO, Propeller uses hardware sampling to gather information
> > > about the frequency of execution of different code paths within a
> > > binary. This information is then used to guide the compiler's
> > > optimization decisions, resulting in a more efficient binary.
> >
> > Thank you for submitting the patches with the latest compiler features.
> >
> > Regarding Propeller, I want to quickly mention that I plan to send a
> > patch to include BOLT as a profile-based post-link optimizer for the
> > kernel. I'd like it to be considered an alternative that is selectable
> > at build time.
> >
> > BOLT also uses sampling, and the profile can be collected on virtually
> > any kernel (with some caveats).  There are no constraints on the
> > compiler (i.e., any version of GCC or Clang is acceptable), while Linux
> > perf is the only external dependency used for profile collection and
> > conversion. BOLT works on top of AutoFDO and LTO but can be used without
> > them if the user desires. The build overhead is a few seconds.
> >
> > As you've heard from the LLVM discussion
> > (https://discourse.llvm.org/t/optimizing-the-linux-kernel-with-autofdo-including-thinlto-and-propeller)
> > and LPC talk (https://lpc.events/event/18/contributions/1921/), at Meta,
> > we've also successfully optimized the kernel and got similar results.
> >
> > Again, this is a heads-up before the patch, and I would like to hear
> > what people think about having a binary optimizer as a user-selectable
> > alternative to Propeller.
> 
> I'd imagine that folks would be interested in running Propeller, or
> BOLT, but perhaps not both.
> 
> In that sense, Kconfig has the means to express mutual exclusion.
> It's perhaps worth working together to get the kconfig selection
> working such that folks can play with enabling these newer toolchain
> related technologies.

Right, I would expect this to just be a Kconfig choice with a
description like "Post link optimization" or something of the sort, like
the RANDSTRUCT or DEBUG_INFO ones. If it does make sense to do them at
the same time, they can obviously be separate.

> The next instance of the bi-weekly public Clang Built Linux meeting is
> next Wednesday. (Links from https://clangbuiltlinux.github.io/)
> 
> Perhaps it's worth Rong (and Sriraman and Han) and Maksim to stop by and chat?

I would certainly be open to discussing the plans for upstreaming these
in the meeting. I think the sessions went well in the Toolchains Track.
There were no major objections from what I could tell.

Cheers,
Nathan