From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18342 invoked by alias); 5 Nov 2014 13:28: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 18330 invoked by uid 89); 5 Nov 2014 13:28:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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; Wed, 05 Nov 2014 13:28:49 +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 sA5DSJKE029842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 5 Nov 2014 08:28:20 -0500 Received: from sandy.ghostprotocols.net (ovpn-113-145.phx2.redhat.com [10.3.113.145]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA5DSI12008228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2014 08:28:19 -0500 Received: by sandy.ghostprotocols.net (Postfix, from userid 1000) id A4FE3EE7E; Wed, 5 Nov 2014 11:28:17 -0200 (BRST) Date: Wed, 05 Nov 2014 13:28:00 -0000 From: Arnaldo Carvalho de Melo To: Masami Hiramatsu Cc: Hemant Kumar , Namhyung Kim , LKML , Srikar Dronamraju , Peter Zijlstra , oleg@redhat.com, hegdevasant@linux.vnet.ibm.com, mingo@redhat.com, anton@redhat.com, systemtap@sourceware.org, aravinda@linux.vnet.ibm.com, penberg@iki.fi, acme@kernel.org Subject: Re: Re: Re: Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events Message-ID: <20141105132817.GE2487@redhat.com> References: <5458CD15.4010101@hitachi.com> <5459BD3E.7010804@linux.vnet.ibm.com> <5459C8BE.30809@linux.vnet.ibm.com> <5459E8BC.8030500@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5459E8BC.8030500@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/msg00106.txt.bz2 Em Wed, Nov 05, 2014 at 06:07:08PM +0900, Masami Hiramatsu escreveu: > (2014/11/05 15:50), Hemant Kumar wrote: > >> And also, user interface is a discussion point. This series defines new > >> sdt-cache command, and we already have buildid-cache command. We should > >> have probe-cache command too? or consolidate those cache managing > >> commands? > >> This question should be involving your series too. > > I think, we need not have multiple sub-commands to manage the cache. We > > can consolidate the cache management of probe events (including SDT > > events) to a single command. > Agreed. maybe perf-cache --buildid/--sdt/--probe would be good. We have it already, its called 'perf buildid-cache': [root@zoo ~]# perf buildid-cache --hell Error: unknown option `hell' usage: perf buildid-cache [] -a, --add file(s) to add -k, --kcore kcore file to add -r, --remove file(s) to remove -M, --missing to find missing build ids in the cache -f, --force don't complain, do it -u, --update file(s) to update -v, --verbose be more verbose [root@zoo ~]# We can rename it at some point to 'perf cache', perhaps. 'perf cache --buildid' makes no sense, everything is keyed by build-id (hence the name, which is albeit long, admit), I guess what you meant was 'elf'. It currently stores content of the form: - ELF - kcore (which is also ELF, but has no pathname) - kallsyms We would be adding other types of content, from this discussion: - sdt - [ku]probes (built from some other content, like ELF or kallsyms) - Arnaldo