----- 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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- 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
