All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Alexei Starovoitov <ast@fb.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	"David S. Miller" <davem@davemloft.net>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	netdev <netdev@vger.kernel.org>, kernel-team <kernel-team@fb.com>,
	linux-api <linux-api@vger.kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time
Date: Wed, 28 Mar 2018 13:04:07 -0400	[thread overview]
Message-ID: <20180328130407.7476cf17@gandalf.local.home> (raw)
In-Reply-To: <67c5f9b4-b24a-2806-e8d6-8b5241c66d6e@fb.com>

On Wed, 28 Mar 2018 09:43:56 -0700
Alexei Starovoitov <ast@fb.com> wrote:
> >
> > Given that only eBPF needs this parameter count, we can move
> > it to the struct bpf_raw_event_map newly introduced by Steven,
> > right ? This would reduce bloat of struct tracepoint. For instance,
> > we don't need to keep this count around when eBPF is configured
> > out.  
> 
> Makes sense. That is indeed cleaner. Will respin.
> 
> What I don't like though is 'bloat' argument.
> 'u32 num_args' padded to 8-byte takes exactly the same amount
> of space in 'struct tracepoint' and in 'struct bpf_raw_event_map'
> The number of these structures is the same as well
> and chances that tracepoints are on while bpf is off are slim.
> More so few emails ago you said:
> "I'm perfectly fine with adding the "num_args" stuff. I think it's
> really useful. It's only the for_each_kernel_tracepoint change for
> which I'm trying to understand the rationale."

I don't really care which one it goes in. The padding bloat is the same
for both :-/  But I wonder if we can shrink it by doing a trick that
Josh did in one of his patches. That is, to use a 32bit offset instead
of a direct pointer. Since you are only accessing core kernel
tracepoints.

Thus, we could have

struct bpf_raw_event_map {
	u32			tp_offset;
	u32			num_args;
	void			*bpf_func;
};

and have:

	u64 tp_offset = (u64)tp - (u64)_sdata;

	if (WARN_ON(tp_offset > UINT_MAX)
		return -EINVAL;

	 btp->tp_offset = (u32)tp_offset;

And to get the tp, all you need to do is:

	tp = (struct tracepoint *)(btp->tp_offset + (unsigned long)_sdata);

I've been thinking of doing this for other parts of the tracepoints and
ftrace code.

BTW, thanks for changing your code. I really appreciate it.

-- Steve

  reply	other threads:[~2018-03-28 17:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28  2:10 [PATCH v7 bpf-next 00/10] bpf, tracing: introduce bpf raw tracepoints Alexei Starovoitov
2018-03-28  2:10 ` Alexei Starovoitov
2018-03-28  2:10 ` [PATCH v7 bpf-next 01/10] treewide: remove large struct-pass-by-value from tracepoint arguments Alexei Starovoitov
2018-03-28  2:10   ` Alexei Starovoitov
2018-03-28  2:10 ` [PATCH v7 bpf-next 02/10] net/mediatek: disambiguate mt76 vs mt7601u trace events Alexei Starovoitov
2018-03-28  2:10   ` Alexei Starovoitov
2018-03-28  2:10 ` [PATCH v7 bpf-next 03/10] net/mac802154: disambiguate mac80215 vs mac802154 " Alexei Starovoitov
2018-03-28  2:10   ` Alexei Starovoitov
2018-03-28  2:10 ` [PATCH v7 bpf-next 04/10] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint Alexei Starovoitov
2018-03-28  2:10   ` Alexei Starovoitov
2018-03-28  2:11 ` [PATCH v7 bpf-next 05/10] macro: introduce COUNT_ARGS() macro Alexei Starovoitov
2018-03-28  2:11   ` Alexei Starovoitov
2018-03-28  2:11 ` [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time Alexei Starovoitov
2018-03-28  2:11   ` Alexei Starovoitov
2018-03-28 13:49   ` Mathieu Desnoyers
2018-03-28 16:43     ` Alexei Starovoitov
2018-03-28 17:04       ` Steven Rostedt [this message]
2018-03-28 17:10         ` Alexei Starovoitov
2018-03-28 17:38           ` Steven Rostedt
2018-03-28 18:03             ` Alexei Starovoitov
2018-03-28 18:10               ` Steven Rostedt
2018-03-28 18:19                 ` Alexei Starovoitov
2018-03-28 18:54                   ` Steven Rostedt
2018-03-28 19:22                     ` Mathieu Desnoyers
2018-03-28 19:25                       ` Alexei Starovoitov
2018-03-28 19:32                       ` Steven Rostedt
2018-03-28 19:38                         ` Steven Rostedt
2018-03-28 19:47                           ` Mathieu Desnoyers
2018-03-28 17:14       ` Mathieu Desnoyers
2018-03-28  2:11 ` [PATCH v7 bpf-next 07/10] bpf: introduce BPF_RAW_TRACEPOINT Alexei Starovoitov
2018-03-28  2:11   ` Alexei Starovoitov
2018-03-28 17:41   ` Steven Rostedt
2018-03-28 17:41     ` Steven Rostedt
2018-03-28  2:11 ` [PATCH v7 bpf-next 08/10] libbpf: add bpf_raw_tracepoint_open helper Alexei Starovoitov
2018-03-28  2:11   ` Alexei Starovoitov
2018-03-28  2:11 ` [PATCH v7 bpf-next 09/10] samples/bpf: raw tracepoint test Alexei Starovoitov
2018-03-28  2:11   ` Alexei Starovoitov
2018-03-28  2:11 ` [PATCH v7 bpf-next 10/10] selftests/bpf: test for bpf_get_stackid() from raw tracepoints Alexei Starovoitov
2018-03-28  2:11   ` Alexei Starovoitov

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=20180328130407.7476cf17@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=ast@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jpoimboe@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-api@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /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.