From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18538 invoked by alias); 28 Oct 2013 08:48:50 -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 18446 invoked by uid 89); 28 Oct 2013 08:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: out4-smtp.messagingengine.com Received: from out4-smtp.messagingengine.com (HELO out4-smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 28 Oct 2013 08:48:48 +0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3B5E8207F7; Mon, 28 Oct 2013 04:48:45 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 28 Oct 2013 04:48:45 -0400 Received: from localhost.localdomain (unknown [82.181.7.205]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A4C7C00E8D; Mon, 28 Oct 2013 04:48:43 -0400 (EDT) Message-ID: <526E24EA.2040701@iki.fi> Date: Mon, 28 Oct 2013 08:48:00 -0000 From: Pekka Enberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: David Ahern , Srikar Dronamraju CC: Hemant Kumar , LKML , Peter Zijlstra , Oleg Nesterov , "hegdevasant@linux.vnet.ibm.com" , Ingo Molnar , "anton@redhat.com" , "systemtap@sourceware.org" , Namhyung Kim , Masami Hiramatsu , "aravinda@linux.vnet.ibm.com" Subject: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers: References: <20131023044511.1886.82571.stgit@hemant-fedora> <20131023050502.1886.15779.stgit@hemant-fedora> <20131025125921.GA29424@linux.vnet.ibm.com> <526A8C2B.7000401@gmail.com> In-Reply-To: <526A8C2B.7000401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q4/txt/msg00106.txt.bz2 Hi David, On 10/25/2013 06:20 PM, David Ahern wrote: > On 10/25/13 8:20 AM, Pekka Enberg wrote: >>> Technically feasible. But then we would have to parse each of the >>> libraries and executables to list them. Right? I am not sure if such a >>> delay is acceptable. >> >> You could do it at 'perf list' time or even build time and cache it. >> And add lazy discovery to 'perf record' and friends. > > Instead searching all the known files or building a cache, how about > just having an option like: perf list . perf-record could still > do the probe magic behind the scenes. We probably should also support that. But I don't see why 'perf list' could not tell me about SDT markers in libraries that are already installed on my system. The problem I have with all the command line magic is that while the tracing mechanisms are awesome, they're nearly impossible to discover even by a power user such as myself and you almost certainly forget the exact syntax over time. It's not as if you're tracing all the time. I wish people remembed how awesome and simple 'perf stat' and 'perf record' with 'perf report' were compared to oprofile when the first versions came out. I think much of the nice perf features are suffering because we're not paying enough attention how to make them accessible to users. The proposed SDT marker feature is a good example of that. I mean, how on earth would I know about the userspace probes unless I read LKML and know that such a feature exists? And why would I want to provide mappings for SDT markers and perf events if I want to trace 'libc:setjmp'? So I really hope this SDT effort and the ktap effort at least make some effort in unifying all the nice functionality that's simple to use and easy to discover. I really, really would at the end of the day, just 'perf trace' like I 'perf stat' or 'perf record'. Pekka