From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Jiri Olsa" <jolsa@redhat.com>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Martin KaFai Lau" <kafai@fb.com>,
"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
"Andrii Nakryiko" <andriin@fb.com>,
"Quentin Monnet" <quentin.monnet@netronome.com>
Subject: Re: [RFC] btf: Some structs are doubled because of struct ring_buffer
Date: Fri, 13 Dec 2019 08:51:57 -0800 [thread overview]
Message-ID: <20191213165155.vimm27wo7brkh3yu@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20191213112438.773dff35@gandalf.local.home>
On Fri, Dec 13, 2019 at 11:25:00AM -0500, Steven Rostedt wrote:
> On Fri, 13 Dec 2019 16:35:53 +0100
> Jiri Olsa <jolsa@redhat.com> wrote:
>
> > I don't think dedup algorithm can handle this and I'm not sure if there's
> > some way in pahole to detect/prevent this.
> >
> > I only found that if I rename the ring_buffer objects to have distinct
> > names, it will help:
> >
> > $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep task_struct
> > [150] STRUCT 'task_struct' size=11008 vlen=205
> >
> > $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "STRUCT 'perf_event'"
> > [1665] STRUCT 'perf_event' size=1160 vlen=70
> >
> > also the BTF data get smaller ;-) before:
> >
> > $ ll /sys/kernel/btf/vmlinux
> > -r--r--r--. 1 root root 2067432 Dec 13 22:56 /sys/kernel/btf/vmlinux
> >
> > after:
> > $ ll /sys/kernel/btf/vmlinux
> > -r--r--r--. 1 root root 1984345 Dec 13 23:02 /sys/kernel/btf/vmlinux
> >
> >
> > Peter, Steven,
> > if above is correct and there's no other better solution, would it be possible
> > to straighten up the namespace and user some distinct names for perf and ftrace
> > ring buffers?
>
> Now, the ring buffer that ftrace uses is not specific for ftrace or
> even tracing for that matter. It is a stand alone ring buffer (oprofile
> uses it), and can be used by anyone else.
>
> As the perf ring buffer is very coupled with perf (or perf events), and
> unless something changed, I was never able to pull the perf ring
> buffer out as a stand alone ring buffer.
>
> As the ring buffer in the tracing directory is more generic, and not to
> mention around longer, if one is to change the name, I would suggest it
> be the perf ring buffer.
Thanks Jiri to bring it up.
Technically the kernel is written in valid C, but it's imo the case where C
standard isn't doing that great.
To rephrase what Jiri said...
If include/linux/perf_event.h instead of saying 'struct ring_buffer;'
would have done #include <kernel/events/internal.h>
the kernel/trace/ring_buffer.c would have had build error.
Even now sizeof(*perf_event->rb) would return different values depending
whether it's used in kernel/trace/ring_buffer.c or anywhere in kernel/events/.
dwarf/btf and gcc cannot deal with it nicely. It's a valid C.
'gdb vmlinux' for sizeof(struct ring_buffer) will pick perf ring buffer.
It had two choices. Both valid. I don't know why gdb picked this one.
So yeah I think renaming 'ring_buffer' either in ftrace or in perf would be
good. I think renaming ftrace one would be better, since gdb picked perf one
for whatever reason.
next prev parent reply other threads:[~2019-12-13 20:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 15:35 [RFC] btf: Some structs are doubled because of struct ring_buffer Jiri Olsa
2019-12-13 16:25 ` Steven Rostedt
2019-12-13 16:51 ` Alexei Starovoitov [this message]
2019-12-13 17:11 ` Steven Rostedt
2019-12-13 17:30 ` Alexei Starovoitov
2019-12-13 18:28 ` Jiri Olsa
2019-12-13 18:02 ` Peter Zijlstra
2019-12-13 18:29 ` Steven Rostedt
2019-12-13 18:36 ` Jiri Olsa
2019-12-13 18:43 ` Steven Rostedt
2019-12-13 18:46 ` Peter Zijlstra
2019-12-13 19:03 ` Steven Rostedt
2019-12-13 19:05 ` Steven Rostedt
2019-12-14 11:35 ` Jiri Olsa
2019-12-18 16:14 ` Jiri Olsa
2019-12-18 16:22 ` Steven Rostedt
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=20191213165155.vimm27wo7brkh3yu@ast-mbp.dhcp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quentin.monnet@netronome.com \
--cc=rostedt@goodmis.org \
--cc=songliubraving@fb.com \
--cc=toke@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).