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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 3592BC4363D for ; Fri, 25 Sep 2020 14:42:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E07C8235F9 for ; Fri, 25 Sep 2020 14:41:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="Cz3UfFGI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729022AbgIYOl6 (ORCPT ); Fri, 25 Sep 2020 10:41:58 -0400 Received: from mail.efficios.com ([167.114.26.124]:36042 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728148AbgIYOl6 (ORCPT ); Fri, 25 Sep 2020 10:41:58 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 3D5282DF81C; Fri, 25 Sep 2020 10:41:57 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id etln7-sBXN62; Fri, 25 Sep 2020 10:41:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id B1E4C2DF818; Fri, 25 Sep 2020 10:41:56 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com B1E4C2DF818 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1601044916; bh=SicV3rSpZim8FrS0ZVWzj64HWG1Cjm6QTjzvGKj+iXY=; h=Date:From:To:Message-ID:MIME-Version; b=Cz3UfFGIG5hDBAsz7lSM8j/fAS2zwaCojsJHR1qvgdAdH+heNRjmuFpAkUUpbqVPr b9JiF54uyuz5mzrgFqJ1irHbjq4iEUYBZ+P5Eb03Pp26stu9qva3hw6ibTToAB//YW E2Cqv6Rg7gV0A6JITiX3Z987gcPcivCSu9+b3ptBSyZypRQICKVsQZYoafxMDx9xvO slbqKZ3X2bVn7btL8QuZQ4Z8jmt50Otux3DJFWnMAM1Fkqa0pCuFv8km4A4vLwfaGf kdXLTppWYYsI73nJ4OcNdEM3AXK0Ryk0oEBHOnavymHTa0bIte7wrQhbPV9ZfhlPUm b1WZzvwudBItA== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id h-uiFheZSZnz; Fri, 25 Sep 2020 10:41:56 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 9F49A2DF643; Fri, 25 Sep 2020 10:41:56 -0400 (EDT) Date: Fri, 25 Sep 2020 10:41:56 -0400 (EDT) From: Mathieu Desnoyers To: rostedt , paulmck , Michael Jeanson Cc: linux-kernel , Yafang Shao , Axel Rasmussen , Andrew Morton , Vlastimil Babka , Michel Lespinasse , Daniel Jordan , Davidlohr Bueso , linux-mm , Ingo Molnar , Joonsoo Kim Message-ID: <176393901.69671.1601044916547.JavaMail.zimbra@efficios.com> In-Reply-To: <20200924163331.0080b943@oasis.local.home> 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> Subject: Re: [PATCH 1/2] tracepoints: Add helper to test if tracepoint is enabled in a header MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3965 (ZimbraWebClient - FF80 (Linux)/8.8.15_GA_3963) Thread-Topic: tracepoints: Add helper to test if tracepoint is enabled in a header Thread-Index: p+VyZlWM1Y67JbKk42e0MfEaE3JsoQ== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Sep 24, 2020, at 4:33 PM, rostedt rostedt@goodmis.org wrote: > On Thu, 24 Sep 2020 16:27:34 -0400 (EDT) > Mathieu Desnoyers wrote: > >> I'd be a bit more specific: so far, the msr.h use-case requires to include >> directly tracepoint-defs.h and use a tracepoint_enabled() macro defined there. >> >> Other less "core" header use-cases could still include tracepoint.h, as long as >> there is no circular dependency. > > Well, I'll keep tracepoint-defs.h for the msr.h case, and I could see > if tracepoint.h is good enough for the other cases. > > But does it really matter, if we only need what is in > tracepoint-defs.h? Why add something that may cause issues in the > future? The trade-off here is tracing (on) speed and code size vs header instrumentation coverage. Adding the trampoline as is done in msr.h adds the overhead of an extra function call when tracing is active. It also slightly increases the code size. This is why we don't have that extra trampoline in the common case. The main limitation with respect to tracepoint instrumentation coverage is header dependencies of RCU read-side synchronization. Currently, tracepoint.h uses rcu-sched and SRCU. Moving that synchronization into a trampoline is one way to work-around circular dependency issues. Note that I have plans to make tracepoint.h use Tasks Trace RCU as well, so some probes can take pages faults (especially useful for sys enter/exit). Michael Jeanson has been working on a prototype implementing this, and he should be able to post a RFC patch publicly soon. That being said, I suspect that Tasks Trace RCU has fewer header dependencies than rcu-sched and SRCU. Maybe one idea worth considering is replacing tracepoint's use of rcu-sched and SRCU by Tasks Trace RCU altogether, if the latter has read-side performance close to rcu-sched. This could be another way to minimize the amount of tracepoint.h header dependencies. 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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com