From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1839 invoked by alias); 23 Oct 2014 05:54: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 1830 invoked by uid 89); 23 Oct 2014 05:54:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 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; Thu, 23 Oct 2014 05:54:30 +0000 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Oct 2014 11:24:25 +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; Thu, 23 Oct 2014 11:24:24 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 31994394004C for ; Thu, 23 Oct 2014 11:24:24 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay02.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s9N5sh5E60489740 for ; Thu, 23 Oct 2014 11:24:43 +0530 Received: from d28av04.in.ibm.com (localhost [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s9N5sMIW028788 for ; Thu, 23 Oct 2014 11:24:23 +0530 Received: from linux.vnet.ibm.com (srdronam.in.ibm.com [9.124.31.34]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id s9N5sMGp028785; Thu, 23 Oct 2014 11:24:22 +0530 Date: Thu, 23 Oct 2014 05:54:00 -0000 From: Srikar Dronamraju To: Masami Hiramatsu Cc: Hemant Kumar , linux-kernel@vger.kernel.org, peterz@infradead.org, oleg@redhat.com, hegdevasant@linux.vnet.ibm.com, mingo@redhat.com, anton@redhat.com, systemtap@sourceware.org, namhyung@kernel.org, aravinda@linux.vnet.ibm.com, penberg@iki.fi Subject: Re: [PATCH v3 5/5] perf/sdt: Add support to perf record to trace SDT events Message-ID: <20141023055422.GA27939@linux.vnet.ibm.com> Reply-To: Srikar Dronamraju References: <20141010104402.15506.73285.stgit@hemant-fedora> <20141010105914.15506.84827.stgit@hemant-fedora> <54475292.20409@hitachi.com> <544768C6.6090105@linux.vnet.ibm.com> <54477BE6.2060006@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54477BE6.2060006@hitachi.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14102305-0009-0000-0000-000001BE1333 X-IsSubscribed: yes X-SW-Source: 2014-q4/txt/msg00078.txt.bz2 * Masami Hiramatsu [2014-10-22 18:41:58]: > (2014/10/22 17:20), Hemant Kumar wrote: > >>> From "file_sdt_ent" we will find out the file name. > >>> Convert this sdt note into a perf event and then write this into uprobe_events > >>> file to be able to record the event. > >>> Then, corresponding entries are added to uprobe_events file for > >>> the SDT events. > >>> After recording is done, these events are silently deleted from uprobe_events > >>> file. The uprobe_events file is present in debugfs/tracing directory. > >>> > >>> To support the addition and deletion of SDT events to/from uprobe_events > >>> file, a record_sdt struct is maintained which has the event data. > >> OK, I have some comments on this. > >> > >>> An example usage: > >>> > >>> # ./perf record -e %user_app:fun_start -aR /home/user_app > >> At first, I'd like to add SDT support for adding probes too, like below; > >> > >> ./perf probe -a '%user_app:fun_start $vars' > > > > But I think, previously we discussed that we won't be having "perf > > probe" for SDT events. > > We list them and probe/trace them using "perf record" directly. > > Right, sorry for confusing you. I meant that I'd like to support SDT on both of > perf-record and perf-probe :) > And even if we'll hide sdt related events via perf, users can access it via ftrace. > So, I doubt that we can completely hide them, in that case, honesty is the best way;) > I am somehow not able to figure out how perf probe comes into the current workflow. I think the current design was 1. perf sdt-cache --add (only once per file) 2. perf record -e So what is the additional thing that perf probe does or Is it going to replace any of the above steps? -- Thanks and Regards Srikar Dronamraju