From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6673 invoked by alias); 26 Oct 2013 09:50:32 -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 6661 invoked by uid 89); 26 Oct 2013 09:50:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ea0-f173.google.com Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com) (209.85.215.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 26 Oct 2013 09:50:30 +0000 Received: by mail-ea0-f173.google.com with SMTP id g10so1193366eak.18 for ; Sat, 26 Oct 2013 02:50:26 -0700 (PDT) X-Received: by 10.14.102.66 with SMTP id c42mr12326894eeg.47.1382781026313; Sat, 26 Oct 2013 02:50:26 -0700 (PDT) Received: from gmail.com (BC24D856.catv.pool.telekom.hu. [188.36.216.86]) by mx.google.com with ESMTPSA id s3sm28876634eeo.3.2013.10.26.02.50.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 26 Oct 2013 02:50:26 -0700 (PDT) Date: Sat, 26 Oct 2013 09:50:00 -0000 From: Ingo Molnar To: Srikar Dronamraju Cc: Pekka Enberg , 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: Message-ID: <20131026095023.GF14237@gmail.com> References: <20131023044511.1886.82571.stgit@hemant-fedora> <20131023050502.1886.15779.stgit@hemant-fedora> <20131025125921.GA29424@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131025125921.GA29424@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-q4/txt/msg00102.txt.bz2 * Srikar Dronamraju wrote: > Hi Pekka, > > > > > > > You can now use it in all perf tools, such as: > > > > > > perf record -e libc:my_event -aR sleep 1 > > > > Is there a technical reason why 'perf list' could not show all the > > available SDT markers on a system and that the 'market to event' > > mapping cannot happen automatically? > > > > 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. I'd say lets try Pekka's suggestion and make it more palatable if there's complaints about the delay. (SSD systems are becoming dominant and there the search should be reasonably fast.) We could also make 'perf list' more sophisticated, if invoked naively as 'perf list' then maybe it should first display the various event categories, with a (rough) count: $ perf list 34 hardware events # use 'perf list --hw' to list them 40 hw-cache events # use 'perf list --cache' to list them 20 software events # use 'perf list --sw' to list them 2 raw events # use 'perf list --raw' to list them 120 tracepoints # use 'perf list --tp' to list them >10 SDT tracepoints # use 'perf list --sdt' to list them # use 'perf list -a' to list all events # use 'perf list ./binary' to list events in a given binary I.e. bring a bit more structure into it. > Also if a binary exists in a path thats is not covered in the > default search, an user might believe that his binary may not have > markers. I know the above reason is more of a user folly than a > tooling issue. I think in 99% of the usecases people will either use pre-built markers that come with their distro, or will be intimately aware of the markers because they are in the very app they are developing. So I wouldn't worry about 'user has a weird binary' case too much. I agree with Pekka that making them easily discoverable and visible as a coherent whole is really important. Thanks, Ingo