From: Mel Gorman <mgorman@techsingularity.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Michal Suchanek <msuchanek@suse.de>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Jiri Olsa <jolsa@kernel.org>, Hritik Vijay <hritikxx8@gmail.com>,
bpf <bpf@vger.kernel.org>, Linux-Net <netdev@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets
Date: Thu, 27 May 2021 10:04:22 +0100 [thread overview]
Message-ID: <20210527090422.GA30378@techsingularity.net> (raw)
In-Reply-To: <YK9SiLX1E1KAZORb@infradead.org>
On Thu, May 27, 2021 at 09:04:24AM +0100, Christoph Hellwig wrote:
> On Wed, May 26, 2021 at 09:07:41AM +0100, Mel Gorman wrote:
> > + !defined(CONFIG_DEBUG_LOCK_ALLOC) && \
> > + !defined(CONFIG_PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT)
> > + /*
> > + * pahole 1.21 and earlier gets confused by zero-sized per-CPU
> > + * variables and produces invalid BTF. Ensure that
> > + * sizeof(struct pagesets) != 0 for older versions of pahole.
> > + */
> > + char __pahole_hack;
> > + #warning "pahole too old to support zero-sized struct pagesets"
> > +#endif
>
> Err, hell no. We should not mess up the kernel for broken tools that
> are not relevant to the kernel build itself ever.
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.
The second alternative fix is to embed the local_lock
within struct per_cpu_pages. It was shown this was possible in
https://lore.kernel.org/linux-rt-users/20210419141341.26047-1-mgorman@techsingularity.net/T/#md1001d7af52ac0d6d214b95e98fe051f9399de64
but I dropped it because it makes the locking protocol complex e.g.
config-specific lock-switchin in free_unref_page_list.
The last one is wrapping local_lock behind #defines and only defining the
per-cpu structures when local_lock_t is a non-zero size. That is simply
too ugly for words, the locking patterns should always be the same.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-05-27 9:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 8:07 [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Mel Gorman
2021-05-26 8:16 ` David Hildenbrand
2021-05-26 8:33 ` (BTF) " Michal Suchánek
2021-05-26 9:00 ` Mel Gorman
2021-05-26 17:00 ` Andrii Nakryiko
2021-05-26 17:43 ` Michal Suchánek
2021-05-26 16:57 ` Andrii Nakryiko
2021-05-26 18:13 ` Mel Gorman
2021-05-26 18:41 ` Andrii Nakryiko
2021-05-27 8:04 ` Christoph Hellwig
2021-05-27 9:04 ` Mel Gorman [this message]
2021-05-27 9:18 ` Christoph Hellwig
2021-05-27 14:37 ` Andrii Nakryiko
2021-05-27 14:41 ` Andrii Nakryiko
2021-05-28 8:09 ` David Laight
2021-05-28 9:04 ` Mel Gorman
2021-05-28 9:49 ` David Laight
2021-05-28 9:56 ` Michal Suchánek
2021-05-28 13:09 ` David Laight
2021-05-30 0:46 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210527090422.GA30378@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hch@infradead.org \
--cc=hritikxx8@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=msuchanek@suse.de \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.