From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28834 invoked by alias); 30 Oct 2013 10:22:45 -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 28826 invoked by uid 89); 30 Oct 2013 10:22:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,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; Wed, 30 Oct 2013 10:22:43 +0000 Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 9F30D33CC2; Wed, 30 Oct 2013 19:22:41 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id r9UAMf06032108; Wed, 30 Oct 2013 19:22:41 +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 r9UAMdlS024205; Wed, 30 Oct 2013 19:22:40 +0900 Received: from gmml27.itg.hitachi.co.jp (unknown [158.213.165.130]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id 969C12F004F; Wed, 30 Oct 2013 19:22:40 +0900 (JST) Received: from [10.198.209.112] by gmml27.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id r9UAMeA6586534; Wed, 30 Oct 2013 19:22:40 +0900 Message-ID: <5270DDEE.8070606@hitachi.com> Date: Wed, 30 Oct 2013 10:22:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Pekka Enberg Cc: David Ahern , Srikar Dronamraju , Hemant Kumar , LKML , Peter Zijlstra , Oleg Nesterov , "hegdevasant@linux.vnet.ibm.com" , Ingo Molnar , "anton@redhat.com" , "systemtap@sourceware.org" , Namhyung Kim , "aravinda@linux.vnet.ibm.com" , "yrl.pp-manager.tt@hitachi.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> <526E24EA.2040701@iki.fi> <526E9808.4030607@gmail.com> <526EB0C3.2080304@iki.fi> In-Reply-To: <526EB0C3.2080304@iki.fi> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00136.txt.bz2 (2013/10/29 3:45), Pekka Enberg wrote: > On 10/28/13 6:59 PM, David Ahern wrote: > > I often use perf-list to lookup an exact event name, and I do not want > > to see it taking many seconds to minutes to run (not everyone is > > running on an SSD). I also run perf on many different OS versions with > > an NFS home directory, and do not want to see a cache explosion (I > > have buildid disabled for this reason). > > I am talking about reasonable defaults - the 'default' part implies that > people can change the behavior. So we absolutely should also have > something like this for power users such as yourself: > > perf config sdt.scan false Ah, I like this perf-config to store the default/customized values ;) > That said, the 'reasonable' part suggests that 'perf list' must not take > seconds or minutes (!) for every run. I'd start with implementing a > naive scan and seeing where it takes us. It's not like it's rocket > science to ignore network mounts or revert to a whitelist of paths if > necessary. I think it is reasonable to scan only $PATH and ld.so.cache (the result of ldconfig --print-cache) by default. :) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com