From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3587 invoked by alias); 7 Nov 2014 10:51:59 -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 3578 invoked by uid 89); 7 Nov 2014 10:51:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e28smtp03.in.ibm.com Received: from e28smtp03.in.ibm.com (HELO e28smtp03.in.ibm.com) (122.248.162.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 07 Nov 2014 10:51:57 +0000 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 7 Nov 2014 16:21:48 +0530 Received: from d28dlp02.in.ibm.com (9.184.220.127) by e28smtp03.in.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 7 Nov 2014 16:21:46 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 71B21394005E for ; Fri, 7 Nov 2014 16:21:45 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay02.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sA7Aq1Te52297940 for ; Fri, 7 Nov 2014 16:22:02 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sA7AphFL007124 for ; Fri, 7 Nov 2014 16:21:44 +0530 Received: from localhost.localdomain ([9.77.199.171]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sA7ApZU9006001; Fri, 7 Nov 2014 16:21:36 +0530 Message-ID: <545CA436.8030306@linux.vnet.ibm.com> Date: Fri, 07 Nov 2014 10:51:00 -0000 From: Hemant Kumar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Masami Hiramatsu , Namhyung Kim , Arnaldo Carvalho de Melo CC: 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, brendan.d.gregg@gmail.com, "yrl.pp-manager.tt@hitachi.com" Subject: Re: [RFC] perf-cache command interface design 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> <545B1DDE.9000202@linux.vnet.ibm.com> <545C80F4.4020905@hitachi.com> In-Reply-To: <545C80F4.4020905@hitachi.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14110710-0009-0000-0000-0000020FFF36 X-SW-Source: 2014-q4/txt/msg00119.txt.bz2 On 11/07/2014 01:51 PM, Masami Hiramatsu wrote: > Hello, > > Here, I've tried to describe my idea of perf-cache subcommand interface. > It is just a design review, not implemented yet :) > Please give me your comments/ideas! Thanks, I have some comments below. > Command-line Synopsis > ===================== > > Current "perf buildid-cache [options]" are directly mapped to > "perf cache --buildid [options]". > > And adding --sdt for managing SDT caches as below. > > Add or update SDT events in > perf cache --sdt --add|--update > Remove all SDT events for > perf cache --sdt --remove > > List all SDT events > perf cache --sdt --list > > And --probes for managing probe-caches as below. > > Add new probe-cache entries for kernel, or . > perf cache --probe [--exec |--module ] --add > > Delete existing probe-cache entries for kernel, or/and . > perf cache --probe --del [:][@][#] > > Or remove all entires for given FILES > perf cache --probe --remove > > List the probe caches(including SDT) for kernel, , or/and . > perf cache --probe --list [@][#] > > Query the probe definitions. > perf cache --probe --query [:][@][#] > > Note that --probes also can be used for managing SDT events, which has % prefix > e.g. > Add all SDT events for > perf cache --probe --exec --add '%*:*' > > Remove some SDT events for > perf cache --probe --del '%some:events@' > > Or remove all SDT events for > perf cache --probe --del '%*:*#' Looks nice to me :) > > File Format > =========== > All the cache files are placed under ~/.debug/ by default. > The paths of buildid cache of binary/symbols are not changed. > > The SDT/probe caches are placed under the ~/.debug/.probes/path/to/bin/bu/ildid > and that is linked to ~/.debug/.probes/.buildid/bu/ildid > # To avoid conflict with files under /probes/*, I picked up .probes/. > > This SDT/probe caches contain probe-definitions as following format. > ---- > #buildid:BUILDID > #path:PATH > p:%PROVIDER/EVENT PATH:OFFSET [ARGS] I think this format isn't accepted by the uprobe_events file (because of the '%') if we want to cat and grep into uprobe_events file directly. Although, in case of perf record, we can process it to remove '%' and then write into uprobe_events file. And, '%' is required as a flag for the SDT entries. So, either we can modify the uprobe_events file to ignore '%' in the event group name (with an additional patch in the SDT series) or we can leave it to the user to write a script which can do some processing to remove '%' and then echo it to uprobe_events file. What would you think? > p:PROBE/EVENT _text+OFFSET [ARGS] > ---- > > Normal probes and SDT cache entries can be mixed in a cache file, we'll > load all the entries and filter by % prefixes. > > > Thank you, > -- Thanks, Hemant Kumar