From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F616C4727C for ; Fri, 25 Sep 2020 15:14:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 77E9621D42 for ; Fri, 25 Sep 2020 15:14:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77E9621D42 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0AE7290000C; Fri, 25 Sep 2020 11:14:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05D69900006; Fri, 25 Sep 2020 11:14:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8ED390000C; Fri, 25 Sep 2020 11:14:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id D165C900006 for ; Fri, 25 Sep 2020 11:14:22 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 91EBD52D1 for ; Fri, 25 Sep 2020 15:14:22 +0000 (UTC) X-FDA: 77301929964.26.sheet37_630403627168 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 322601804B661 for ; Fri, 25 Sep 2020 15:14:22 +0000 (UTC) X-HE-Tag: sheet37_630403627168 X-Filterd-Recvd-Size: 3171 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Sep 2020 15:14:21 +0000 (UTC) Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D1E4A20878; Fri, 25 Sep 2020 15:14:17 +0000 (UTC) Date: Fri, 25 Sep 2020 11:14:15 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: paulmck , Michael Jeanson , linux-kernel , Yafang Shao , Axel Rasmussen , Andrew Morton , Vlastimil Babka , Michel Lespinasse , Daniel Jordan , Davidlohr Bueso , linux-mm , Ingo Molnar , Joonsoo Kim Subject: Re: [PATCH 1/2] tracepoints: Add helper to test if tracepoint is enabled in a header Message-ID: <20200925111415.60f5334c@oasis.local.home> In-Reply-To: <176393901.69671.1601044916547.JavaMail.zimbra@efficios.com> References: <20200924170928.466191266@goodmis.org> <20200924143025.58dc3c1f@gandalf.local.home> <166273261.68446.1600974510284.JavaMail.zimbra@efficios.com> <20200924153517.73f5f257@oasis.local.home> <221547373.69067.1600977935633.JavaMail.zimbra@efficios.com> <20200924161328.760f5e79@oasis.local.home> <1430794518.69084.1600979254425.JavaMail.zimbra@efficios.com> <20200924163331.0080b943@oasis.local.home> <176393901.69671.1601044916547.JavaMail.zimbra@efficios.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 25 Sep 2020 10:41:56 -0400 (EDT) Mathieu Desnoyers wrote: > With the current dependencies of tracepoint.h, I would argue that we should > only do the trampoline work-around for cases where there is an unavoidable > circular dependency, like the case of msr.h. For other headers which don't > have circular dependency issues with tracepoint.h, we should use the usual > tracepoint instrumentation because not having the trampoline provides better > tracing (on) speed and reduces (slightly) code size. Well, for now, I'm going to add the helper function and have the header use cases use that. A while back ago I had patches that moves the DO_TRACE() work into a separate function and with that we probably could have let all tracepoints be in headers (as they would all just do a function call to the trace algorithm that does the rest of the work). But you balked at that because of the added overhead with tracing on. Anyway, I don't see any issues with the current patch set as is (besides the documentation fix, which I already updated locally). And will add this to my queue for linux-next. -- Steve