From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build time Date: Wed, 28 Mar 2018 12:25:44 -0700 Message-ID: References: <20180328021105.4061744-1-ast@fb.com> <20180328130407.7476cf17@gandalf.local.home> <20180328133830.3d5d74d3@gandalf.local.home> <80d7af37-10ef-28d7-f03f-27b4b5849cd1@fb.com> <20180328141045.1202afeb@gandalf.local.home> <20180328145431.687643bc@gandalf.local.home> <842190155.225.1522264944386.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Daniel Borkmann , Linus Torvalds , Peter Zijlstra , netdev , kernel-team , linux-api , Josh Poimboeuf To: Mathieu Desnoyers , rostedt Return-path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:35164 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752611AbeC1T0k (ORCPT ); Wed, 28 Mar 2018 15:26:40 -0400 In-Reply-To: <842190155.225.1522264944386.JavaMail.zimbra@efficios.com> Sender: netdev-owner@vger.kernel.org List-ID: On 3/28/18 12:22 PM, Mathieu Desnoyers wrote: > > ----- On Mar 28, 2018, at 2:54 PM, rostedt rostedt@goodmis.org wrote: > >> On Wed, 28 Mar 2018 11:19:34 -0700 >> Alexei Starovoitov wrote: >> >>> On 3/28/18 11:10 AM, Steven Rostedt wrote: >>>> On Wed, 28 Mar 2018 11:03:24 -0700 >>>> Alexei Starovoitov 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.