On 3/28/18 12:22 PM, Mathieu Desnoyers wrote:
----- On Mar 28, 2018, at 2:54 PM, rostedt rostedt@xxxxxxxxxxx wrote:
On Wed, 28 Mar 2018 11:19:34 -0700
Alexei Starovoitov <ast@xxxxxx> wrote:
On 3/28/18 11:10 AM, Steven Rostedt wrote:
On Wed, 28 Mar 2018 11:03:24 -0700
Alexei Starovoitov <ast@xxxxxx> 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?
32bit bloat ;-)
But I agree, it's not worth uglifying it.
-- Steve
cache hot/cold argument clearly doesn't apply.
In the current situation I'm fine with adding this extra field
to struct tracepoint. However, we should keep in mind to move
all non-required cache-cold fields to a separate section at
some point. Clearly just this single field won't make a difference
due to other fields and padding.
Submitted v8 where num_args is moved to bpf side.
Please ack it.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
