bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).