Re: [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets

From: Andrii Nakryiko
Date: Thu May 27 2021 - 10:42:00 EST


On Thu, May 27, 2021 at 7:37 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Thu, May 27, 2021 at 2:19 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> >
> > On Thu, May 27, 2021 at 10:04:22AM +0100, Mel Gorman wrote:
> > > What do you suggest as an alternative?
> > >
> > > I added Arnaldo to the cc as he tagged the last released version of
> > > pahole (1.21) and may be able to tag a 1.22 with Andrii's fix for pahole
> > > included.
> > >
> > > The most obvious alternative fix for this issue is to require pahole
> > > 1.22 to set CONFIG_DEBUG_INFO_BTF but obviously a version 1.22 that works
> > > needs to exist first and right now it does not. I'd be ok with this but
> > > users of DEBUG_INFO_BTF may object given that it'll be impossible to set
> > > the option until there is a release.
> >
> > Yes, disable BTF. Empty structs are a very useful feature that we use
> > in various places in the kernel. We can't just keep piling hacks over
> > hacks to make that work with a recent fringe feature.

Sorry, I accidentally send out empty response.

CONFIG_DEBUG_INFO_BTF is a crucial piece of modern BPF ecosystem. It
is enabled by default by most popular Linux distros. So it's hardly a
fringe feature and is something that many people and applications
depend on.

I agree that empty structs are useful, but here we are talking about
per-CPU variables only, which is the first use case so far, as far as
I can see. If we had pahole 1.22 released and widely packaged it could
have been a viable option to force it on everyone. But right now
that's not the case. So while ugly, making sure pagesets is
non-zero-sized is going to avoid a lot of pain for a lot of people. By
the time we need another zero-sized per-CPU var, we might be able to
force pahole to 1.22.