[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBX3nRWtc6+EI13W@krava>
Date: Sat, 18 Mar 2023 18:40:45 +0100
From: Jiri Olsa <olsajiri@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jiri Olsa <olsajiri@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>,
Hao Luo <haoluo@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
bpf@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-perf-users@...r.kernel.org, Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>,
Stanislav Fomichev <sdf@...gle.com>,
Daniel Borkmann <daniel@...earbox.net>,
Namhyung Kim <namhyung@...il.com>,
Dave Chinner <david@...morbit.com>
Subject: Re: [PATCHv3 bpf-next 0/9] mm/bpf/perf: Store build id in file object
On Sat, Mar 18, 2023 at 03:16:45PM +0000, Matthew Wilcox wrote:
> On Sat, Mar 18, 2023 at 09:33:49AM +0100, Jiri Olsa wrote:
> > On Thu, Mar 16, 2023 at 05:34:41PM +0000, Matthew Wilcox wrote:
> > > On Thu, Mar 16, 2023 at 06:01:40PM +0100, Jiri Olsa wrote:
> > > > hi,
> > > > this patchset adds build id object pointer to struct file object.
> > > >
> > > > We have several use cases for build id to be used in BPF programs
> > > > [2][3].
> > >
> > > Yes, you have use cases, but you never answered the question I asked:
> > >
> > > Is this going to be enabled by every distro kernel, or is it for special
> > > use-cases where only people doing a very specialised thing who are
> > > willing to build their own kernels will use it?
> >
> > I hope so, but I guess only time tell.. given the response by Ian and Andrii
> > there are 3 big users already
>
> So the whole "There's a config option to turn it off" shtick is just a
> fig-leaf. I won't ever see it turned off. You're imposing the cost of
> this on EVERYONE who runs a distro kernel. And almost nobody will see
> any benefits from it. Thanks for admitting that.
>
sure, I understand that's legit way of looking at this
I can imagine distros would have that enabled for debugging version of
the kernel (like in fedora), and if that proves to be useful the standard
kernel might take it, but yes, there's price (for discussion as pointed
by Andrii) and it'd be for the distro maintainers to decide
jirka
Powered by blists - more mailing lists