From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29902 invoked by alias); 22 Oct 2014 06:45:49 -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 29891 invoked by uid 89); 22 Oct 2014 06:45:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail7.hitachi.co.jp Received: from mail7.hitachi.co.jp (HELO mail7.hitachi.co.jp) (133.145.228.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Oct 2014 06:45:46 +0000 Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 6D63B37AD4; Wed, 22 Oct 2014 15:45:44 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id s9M6jifK001118; Wed, 22 Oct 2014 15:45:44 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id s9M6jgn2005621; Wed, 22 Oct 2014 15:45:43 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 8F11D490041; Wed, 22 Oct 2014 15:45:42 +0900 (JST) Received: from [10.198.220.54] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 69M6396770000E794; Wed, 22 Oct 2014 15:45:42 +0900 Message-ID: <54475292.20409@hitachi.com> Date: Wed, 22 Oct 2014 06:45:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hemant Kumar 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, 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 References: <20141010104402.15506.73285.stgit@hemant-fedora> <20141010105914.15506.84827.stgit@hemant-fedora> In-Reply-To: <20141010105914.15506.84827.stgit@hemant-fedora> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q4/txt/msg00069.txt.bz2 Hi Hemant, (2014/10/10 19:59), Hemant Kumar wrote: > The SDT events are already stored in a cache file > (/var/cache/perf/perf-sdt-file.cache). Please describe what this patch does at first. > Although the file_hash table helps in addition or deletion of SDT events from the > cache, its not of much use when it comes to probing the actual SDT event, > because the key to this hash list is a file name and not the SDT event name > (which is given as an argument to perf record). So, we won't be able to hash > into it. > > To avoid this problem, we can create another hash list "event_hash" list which > will be maintained along with the file_hash list. > Whenever a user invokes 'perf record -e %provider:event, perf should initialize > the event_hash list and the file_hash list. > The key to event_hash list is calculated from the event name and its > provider name. > > event_hash sdt_note > |---------| ---------------- > | | | file_ptr |==> container file_sdt_ent > key = 129 =>| hlist ==|===|=> event_list=|==> to sdt notes hashed to > | | | name | same entry > |---------| | provider | > | | | note_list==|==> to other notes in the > key = 130 =>| hlist | --------------- same file > |---------| > > The entry at that key in event_hash contains a list of SDT notes hashed to the > same entry. It compares the name and provider to see if that is the SDT note we > are looking for. If yes, find out the file that contains this SDT note. There is > a file_ptr pointer embedded in this note which points to the struct file_sdt_ent > contained in the file_hash. 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' So, maybe we don't need to remove the SDT-based events silently, nor hide it from users. I think you just need to add new sdt events and verify it if there is. BTW, for silently adding event, I'll introduce --quite(-q) option for perf probe. So you'll just need to set silent flag with that. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com