From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17751 invoked by alias); 11 Nov 2014 13:10:53 -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 17737 invoked by uid 89); 11 Nov 2014 13:10:52 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 11 Nov 2014 13:10:51 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sABDAX3D013309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 11 Nov 2014 08:10:33 -0500 Received: from sandy.ghostprotocols.net (ovpn-113-21.phx2.redhat.com [10.3.113.21]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sABDAV36024417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 11 Nov 2014 08:10:32 -0500 Received: by sandy.ghostprotocols.net (Postfix, from userid 1000) id BE536407; Tue, 11 Nov 2014 11:10:30 -0200 (BRST) Date: Tue, 11 Nov 2014 13:10:00 -0000 From: Arnaldo Carvalho de Melo To: Masami Hiramatsu Cc: Hemant Kumar , Namhyung Kim , 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 Message-ID: <20141111131030.GG4468@redhat.com> References: <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> <54609A8C.4050308@hitachi.com> <20141110122321.GC4468@redhat.com> <5461B276.50004@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5461B276.50004@hitachi.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.20 (2009-12-10) X-IsSubscribed: yes X-SW-Source: 2014-q4/txt/msg00141.txt.bz2 Em Tue, Nov 11, 2014 at 03:53:42PM +0900, Masami Hiramatsu escreveu: > (2014/11/10 21:23), Arnaldo Carvalho de Melo wrote: > > Em Mon, Nov 10, 2014 at 07:59:24PM +0900, Masami Hiramatsu escreveu: > >> Here is the second try for the probe-cache. This version simplifies > >> the synopsis, and unifies the SDT and probe caches. > >> Please give me your comments/ideas! > >> > >> Command-line Synopsis > >> ===================== > >> Add elf(or symbols) and probe-caches of SDT if exists in > >> perf cache --add [--probe ] # for user programs > > Why the --probe above? Shouldn't this be just (if you are talking about > > ELF files only): > > perf cache --add > Yes, for the elf and sdt cache, we don't need --probe. > Note that "[]" means optional. If we would like to add some probe cache, > we need a spec of probe definition. I understand that, its just that it looked superfluous at that specific place, where you are explaining how to add ELF files. > >> perf cache --kcore [--probe ] # for kcore ? > > Adrian, aren't kcore files easily identifiable as such and thus could be > > added as: > > perf cache --add > >> perf cache --probe # for the current kernel > > Why do we need a --probe here? Don't they always start with a character > > that is seldomly used in ELF file names and thus we could get away with > > not requiring --probe? > This is only for adding the probe cache (not elf, nor sdt), which requires > a probe definition. Moreover, I'd like to unify the specification of the > probe definition with perf-probe. In that case, --probe is more natural. What I meant was, what is wrong with replacing: perf cache --probe # for the current kernel With: perf cache --add # for the current kernel And have it figure out that what is being added is a probe and do the right thing? > >> Remove caches related to or > >> perf cache --remove | > >> > >> Show all probe caches(including SDT) or buildids > >> perf cache --list [probe|buildid] > >> > >> Delete existing probe-cache entries for kernel, or/and . > >> perf cache　--probe-del [:][@][#] > > > > Ditto, i.e. can't we just use: > > > > perf cache　--remove [:][@][#] > > > > And it figure out that this is a probe that is being removed? > > In most cases, it may be OK, but it is also possible to cause unexpected > result when mis-typing. I think if is always starting at '/', it > is easy to identify. We can keep the explicit switch (--probe-del) perhaps to resolve ambiguities, if they happen, but make it so that it is not strictly required for the common case. - Thanks, - Arnaldo