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,URIBL_BLOCKED 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 1B659C4727F for ; Fri, 25 Sep 2020 22:23:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8554D22211 for ; Fri, 25 Sep 2020 22:23:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="EPHZKca6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8554D22211 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 B28BF6B005C; Fri, 25 Sep 2020 18:23:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB2E26B0062; Fri, 25 Sep 2020 18:23:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97A9F8E0001; Fri, 25 Sep 2020 18:23:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 7DCD46B005C for ; Fri, 25 Sep 2020 18:23:38 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3ADC73D0F for ; Fri, 25 Sep 2020 22:23:38 +0000 (UTC) X-FDA: 77303011716.18.stage57_590dc9d2716b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 68B39101A9437 for ; Fri, 25 Sep 2020 22:23:36 +0000 (UTC) X-HE-Tag: stage57_590dc9d2716b X-Filterd-Recvd-Size: 6360 Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Sep 2020 22:23:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 53B1C2D24DA; Fri, 25 Sep 2020 18:23:35 -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 MzbI1bNxLp4d; Fri, 25 Sep 2020 18:23:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id EA1D92D25D2; Fri, 25 Sep 2020 18:23:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com EA1D92D25D2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1601072615; bh=gQoN2wPqNS+dpQu2jHy+0fCG7sG+iR/HyLFfUk3yxvU=; h=Date:From:To:Message-ID:MIME-Version; b=EPHZKca6RVotJ2EjUXeuTdjADZBOkBr1St5hfLEM5uSfKS25GQd5+PPgNP/pHtoxM JgixCb8zRDx2dp/wYgioiBiv6mbcbplT2B+Zs0rwgj1vD/FcvG+HV0lMKZC+/Jjicf pooiDUJSwDExTNgJMKJWUQnmftCRLsEwygvX69JJ9DPzZZLgInpwjDWCO5kS4V3Ngx rNv+lMgTOeX4gIAlUuI9qwo1tttQVg1Kaoqklnobpr06gHeXXZsrvEESdgcNJkvCSB UJDx0r5Y8oUV4eb/35pZLOqrr5pDmSeI3GLGFDmlY6YbZqwIFbfHPfOactoN2vtQ0I DaRjLBQ8igNYA== 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 ueqY3Mk9kQap; Fri, 25 Sep 2020 18:23:34 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id DB53A2D25D1; Fri, 25 Sep 2020 18:23:34 -0400 (EDT) Date: Fri, 25 Sep 2020 18:23:34 -0400 (EDT) From: Mathieu Desnoyers To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Yafang Shao , Axel Rasmussen , Andrew Morton , Vlastimil Babka , Michel Lespinasse , Daniel Jordan , Davidlohr Bueso , Linux MM , Ingo Molnar , Joonsoo Kim Message-ID: <606086581.69952.1601072614802.JavaMail.zimbra@efficios.com> In-Reply-To: <20200925172640.701ca0a7@oasis.local.home> References: <20200925211206.423598568@goodmis.org> <20200925172640.701ca0a7@oasis.local.home> Subject: Re: [PATCH 0/3 v2] tracing/mm: Add tracepoint_enabled() helper function for headers 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 (zclient/8.8.15_GA_3965) Thread-Topic: tracing/mm: Add tracepoint_enabled() helper function for headers Thread-Index: X5CnxcGKVxo6UTP7Vy2I8qU5DLTdog== 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: No worries, I'll get it from lore. Thanks, Mathieu ----- Steven Rostedt wrote: > > Bah, My cut-and-paste of my "quilt mail --send" chopped off Mathieu's email. > > Mathieu, I didn't meant to not Cc you on this. Do you need me to bounce > the rest to you or you can get it from lore? > > -- Steve > > > On Fri, 25 Sep 2020 17:12:06 -0400 > Steven Rostedt wrote: > > > Tracepoints are not safe to be called directly from header files as they may > > be included by C code that has CREATE_TRACE_POINTS defined, and this would > > cause side effects and possibly break the build in hard to debug ways. Not > > to mention it also will bloat the code being in commonly used inline > > functions. > > > > Instead, it is recommended to call a tracepoint helper function that is > > defined in a C file that calls the tracepoint. But we would only want this > > function to be called if the tracepoint is enabled, as function calls add > > overhead. > > > > The trace__enabled() function is also not safe to be called in a > > header file as it is created by the tracepoint header, which suffers the > > same fate if CREATE_TRACE_POINTS is defined. Instead, the tracepoint needs > > to be declared as an extern, and the helper function can test the static key > > to call the helper function that calls the tracepoint. > > > > This has been done by open coding the tracepoint extern and calling the > > static key directly: > > > > commit 95813b8faa0cd ("mm/page_ref: add tracepoint to track down page reference manipulation") > > commit 7f47d8cc039f ("x86, tracing, perf: Add trace point for MSR accesses") > > > > does this (back in 2015). Now we have another use case, so a helper function > > should be created to keep the internals of the tracepoints from being spread > > out in other subsystems. > > > > Link: https://lore.kernel.org/r/20200922125113.12ef1e03@gandalf.local.home > > > > This adds tracepoint_enabled() helper macro and DECLARE_TRACEPOINT() macro > > to allow this to be done without exposing the internals of the tracepoints. > > > > The first patch adds the infrastructure, the second converts page_ref over > > to it, and third converts over msr.h. > > > > Steven Rostedt (VMware) (3): > > tracepoints: Add helper to test if tracepoint is enabled in a header > > mm/page_ref: Convert the open coded tracepoint enabled to the new helper > > x86: Use tracepoint_enabled() for msr tracepoints instead of open coding it > > > > ---- > > > > Changes since v1 (https://lore.kernel.org/r/20200924170928.466191266@goodmis.org): > > > > - Fixed using "trace_enabled()" instead of "tracepoint_enabled()" > > (Mathieu Desnoyers reported) > > > > - Reworded to include comments about bloating the kernel when tracepoints > > are used in commonly used inlined functions. > > > > - Added the msr update as well. > > > > > > Documentation/trace/tracepoints.rst | 27 ++++++++++++++++++++++++ > > arch/x86/include/asm/msr.h | 18 +++++++--------- > > include/linux/page_ref.h | 42 ++++++++++++++++++------------------- > > include/linux/tracepoint-defs.h | 34 ++++++++++++++++++++++++++++++ > > 4 files changed, 90 insertions(+), 31 deletions(-) > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com