[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5c8ff7c-8185-a3fd-89eb-45ddc099c03b@fb.com>
Date: Wed, 28 Mar 2018 11:19:34 -0700
From: Alexei Starovoitov <ast@...com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
netdev <netdev@...r.kernel.org>,
kernel-team <kernel-team@...com>,
linux-api <linux-api@...r.kernel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build
time
On 3/28/18 11:10 AM, Steven Rostedt wrote:
> On Wed, 28 Mar 2018 11:03:24 -0700
> Alexei Starovoitov <ast@...com> wrote:
>
>> I can live with this overhead if Mathieu insists,
>> but I prefer to keep it in 'struct tracepoint'.
>>
>> Thoughts?
>
> I'm fine with keeping it as is. We could probably use it for future
> enhancements in perf and ftrace.
>
> Perhaps, we should just add a:
>
> #ifdef CONFIG_BPF_EVENTS
>
> Around the use cases of num_args.
it sounds like a good idea, but implementation wise
it will be ifdef CONFIG_BPF_EVENTS around u32 num_args;
in struct tracepoint and similar double definition of
DEFINE_TRACE_FN. One that uses num_args to init
struct tracepoint and one that doesn't ?
Feels like serious uglification of already macros heavy code.
Also what it will address?
cache hot/cold argument clearly doesn't apply.
Powered by blists - more mailing lists