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 4AF75C4727C for ; Fri, 25 Sep 2020 14:42:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC36521D42 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" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC36521D42 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1EBA96B005C; Fri, 25 Sep 2020 10:41:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 175726B005D; Fri, 25 Sep 2020 10:41:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03DAF8E0001; Fri, 25 Sep 2020 10:41:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id DCE826B005C for ; Fri, 25 Sep 2020 10:41:58 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 99F1D181AC9CC for ; Fri, 25 Sep 2020 14:41:58 +0000 (UTC) X-FDA: 77301848316.04.bite17_410d45127168 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 68CF98011C8B for ; Fri, 25 Sep 2020 14:41:58 +0000 (UTC) X-HE-Tag: bite17_410d45127168 X-Filterd-Recvd-Size: 5884 Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Sep 2020 14:41:57 +0000 (UTC) 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== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: ----- 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