From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8577 invoked by alias); 6 Nov 2014 05:34:01 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 8568 invoked by uid 89); 6 Nov 2014 05:33:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail4.hitachi.co.jp Received: from mail4.hitachi.co.jp (HELO mail4.hitachi.co.jp) (133.145.228.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Nov 2014 05:33:57 +0000 Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 7B1DF33CC6; Thu, 6 Nov 2014 14:33:55 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id sA65XtsO018426; Thu, 6 Nov 2014 14:33:55 +0900 Received: from vshuts01.hitachi.co.jp (vshuts01.hitachi.co.jp [10.201.6.83]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id sA65XrUV003327; Thu, 6 Nov 2014 14:33:54 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id 99CA62F0042; Thu, 6 Nov 2014 14:33:53 +0900 (JST) Received: from [10.198.219.30] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 6A651XH1P0000E370; Thu, 06 Nov 2014 14:33:53 +0900 Message-ID: <545B083D.2000205@hitachi.com> Date: Thu, 06 Nov 2014 05:34:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Josh Stone Cc: Namhyung Kim , Hemant Kumar , linux-kernel@vger.kernel.org, srikar@linux.vnet.ibm.com, peterz@infradead.org, oleg@redhat.com, hegdevasant@linux.vnet.ibm.com, mingo@redhat.com, systemtap@sourceware.org, aravinda@linux.vnet.ibm.com, penberg@iki.fi, Arnaldo Carvalho de Melo Subject: Re: Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events References: <20141102105006.21708.28734.stgit@hemant-fedora> <20141102105557.21708.19032.stgit@hemant-fedora> <87lhnr5sbl.fsf@sejong.aot.lge.com> <54588905.7040002@linux.vnet.ibm.com> <5458CD15.4010101@hitachi.com> <874muew2hk.fsf@sejong.aot.lge.com> <5459E865.6050207@hitachi.com> <545AD9C7.50205@redhat.com> In-Reply-To: <545AD9C7.50205@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q4/txt/msg00111.txt.bz2 (2014/11/06 11:15), Josh Stone wrote: > On 11/05/2014 01:05 AM, Masami Hiramatsu wrote: >> [Off topic] I really don't like that the current SDT's semaphore. If the user apps >> see the instruction at the probe point, it is easy to check whether the event is >> enabled or not. Thus I recommend to change its implementation and update version >> instead of supporting current semaphore by perftools. > > You and I have banged heads on this before, but I don't think checking > the instruction is a simple as you seem to think. I invite you to > prototype this, and if you get it working we can discuss the tradeoffs. Would you have the prototype? I'd like to look :) > The good news is that other tools (stap and gdb) won't need to care. If > the SDT semaphore goes automatic, then we can just set that note field > to zero, unused from the tool's perspective. > > Another tactic is to just discourage developers from using the semaphore > in the first place, as it's a completely optional feature. The marker > is just a NOP, so adding some "if (enabled) {...}" around it is often a > useless load and branch. It does make sense if the probe wants to > provide some expensively-computed arguments though, like cpython does to > prepare a function name string. So if you see a project testing the > semaphore around simple arguments, I'd suggest they just probe directly > instead. I see, and we did that on qemu. I consider that someone maybe use it in the future unless we remove it. If we can succeed to discourage people using semaphore, we also should remove it. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com