public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Hemant Kumar <hemant@linux.vnet.ibm.com>
To: Namhyung Kim <namhyung@kernel.org>
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,
	       masami.hiramatsu.pt@hitachi.com,
	aravinda@linux.vnet.ibm.com,        penberg@iki.fi
Subject: Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events
Date: Tue, 04 Nov 2014 08:06:00 -0000	[thread overview]
Message-ID: <54588905.7040002@linux.vnet.ibm.com> (raw)
In-Reply-To: <87lhnr5sbl.fsf@sejong.aot.lge.com>

Hi Namhyung,

On 11/04/2014 01:08 PM, Namhyung Kim wrote:
> Hi Hemant,
>
> As you know, you need to keep an eye on how (kprobes) event cache
> patchset from Masami settles down.  For those who aren't CC'ed, please
> see the link below:
>
>    https://lkml.org/lkml/2014/10/31/207
>
> On Sun, 02 Nov 2014 16:26:28 +0530, Hemant Kumar wrote:
>> This patch adds support to perf to record SDT events. When invoked,
>> the SDT event is looked up in the sdt-cache. If its found, an entry is
>> made silently to uprobe_events file and then recording is invoked, and
>> then the entry for the SDT event in uprobe_events is silently discarded.
>>
>> The SDT events are already stored in a cache file
>> (/var/cache/perf/perf-sdt-file.cache).
>> 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.
> It likely to be ended up with per-file or per-buildid cache files under
> ~/.debug directory.  In this case we also need to have the (central)
> event-to-cache table anyway IMHO.
>
>
>> 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.
> Isn't it enough just to use provide name?  I guess the provider names
> are (should be?) unique among a system although there's no absolute
> guarantee for that.
>

Yes, there is no guarantee for the provider names to be unique.
If we use only provider name with "perf record", then, what if a user 
wants to trace
only a specific SDT event (not all the events for that provider)?
What do you think?

>>              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.
>>
>> An example usage:
>>
>> # perf record -e %libc:setjmp -aR sleep 10
>> [ perf record: Woken up 1 times to write data ]
>> [ perf record: Captured and wrote 0.277 MB perf.data (~12103 samples) ]
>>
>> # perf report --stdio
>> # To display the perf.data header info, please use --header/--header-only
>> #
>> # Samples: 1  of event 'libc:setjmp'
>> # Event count (approx.): 1
>> #
>> # Overhead  Command  Shared Object  Symbol
>> # ........  .......  .............  ...............
>> #
>>     100.00%  sleep    libc-2.16.so   [.] __sigsetjmp
>>
>>
>> Signed-off-by: Hemant Kumar <hemant@linux.vnet.ibm.com>
>
> [SNIP]
>> +/* Session specific to SDT tracing */
>> +struct record_sdt {
>> +	bool    sdt;    /* is this SDT event tracing? */
>> +	char    *str;   /* hold the event name */
>> +} rec_sdt;
>> +
>> +int trace_sdt_event(const char *str)
>> +{
>> +	int ret = 0;
>> +
>> +	rec_sdt.sdt = true;
>> +	rec_sdt.str = strdup(str);
>> +	if (!rec_sdt.str)
>> +		return -ENOMEM;
>> +	ret = event_hash_list__lookup(str);
>> +	return ret;
>> +}
> Hmm.. does it support multiple SDT events recorded in a session like:
>
>    # perf record -e %libc:setjmp -e %libc:longjmp -aR sleep 10
>
> ?

Yes, it supports multiple SDT events recorded in a session :

# ./perf record -e %libc:lll_lock_wait_private -e %libc:setjmp -aR sleep 10
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.264 MB perf.data (~11526 samples) ]

> [SNIP]
>> +/* Parse an SDT event */
>> +static int parse_perf_sdt_event(struct perf_sdt_event *sev,
>> +				struct perf_probe_event *pev)
>> +{
>> +	struct perf_probe_point *pp = &pev->point;
>> +
>> +	pev->uprobes = true;
>> +	pev->sdt = true;
>> +	pev->event = strdup(sev->note->name);
>> +	if (pev->event == NULL)
>> +		return -ENOMEM;
>> +	pev->group = strdup(sev->note->provider);
>> +	if (pev->event == NULL)
> s/event/group/

Will fix that.

>> +		return -ENOMEM;
>> +
>> +	pp->file = strdup(sev->file_name);
>> +	if (pp->file == NULL)
>> +		return -ENOMEM;
>> +
>> +	pp->function = strdup(sev->note->name);
> Missing NULL check.  Also you need to free prior allocations in case of
> error.

Yes, will do that.

> Thanks,
> Namhyung
>
>
>> +	pp->offset = sev->note->addr.a64[0];
>> +	return 0;
>> +}

-- 
Thanks,
Hemant Kumar

  reply	other threads:[~2014-11-04  8:06 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 12:40 [PATCH v4 0/5] perf/sdt: SDT events listing/probing Hemant Kumar
2014-11-02 12:41 ` [PATCH v4 1/5] perf/sdt: ELF support for SDT Hemant Kumar
2014-11-02 12:42 ` [PATCH v4 3/5] perf/sdt: Show SDT cache contents Hemant Kumar
2014-11-02 12:42 ` [PATCH v4 4/5] perf/sdt: Delete SDT events from cache Hemant Kumar
2014-11-02 12:42 ` [PATCH v4 2/5] perf/sdt: Add SDT events into a cache Hemant Kumar
2014-11-02 12:43 ` [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events Hemant Kumar
2014-11-04  7:38   ` Namhyung Kim
2014-11-04  8:06     ` Hemant Kumar [this message]
2014-11-04 12:57       ` Masami Hiramatsu
     [not found]         ` <5459BD3E.7010804@linux.vnet.ibm.com>
2014-11-05  6:51           ` Hemant Kumar
2014-11-05  9:07             ` Masami Hiramatsu
2014-11-05 13:28               ` Arnaldo Carvalho de Melo
2014-11-05  7:06         ` Namhyung Kim
2014-11-05  9:05           ` Masami Hiramatsu
2014-11-06  2:16             ` Josh Stone
2014-11-06  5:34               ` Masami Hiramatsu
2014-11-06  7:06             ` Hemant Kumar
2014-11-06 14:56               ` Masami Hiramatsu
2014-11-07  8:21               ` [RFC] perf-cache command interface design Masami Hiramatsu
2014-11-07  8:42                 ` Peter Zijlstra
2014-11-07 13:58                   ` [PATCH RESEND 1/2] perf tools: Move disable_buildid_cache() to util/build-id.c Namhyung Kim
2014-11-07 13:58                     ` [PATCH 2/2] perf tools: Add record.use-buildid-cache config option Namhyung Kim
2014-11-07 15:16                   ` [RFC] perf-cache command interface design David Ahern
2014-11-07 15:33                     ` Arnaldo Carvalho de Melo
2014-11-07 10:51                 ` Hemant Kumar
2014-11-08  4:15                   ` Masami Hiramatsu
2014-11-07 14:38                 ` Arnaldo Carvalho de Melo
2014-11-08  4:26                   ` Masami Hiramatsu
2014-11-07 14:43                 ` Namhyung Kim
2014-11-08  4:38                   ` Masami Hiramatsu
2014-11-10 10:59                 ` Masami Hiramatsu
2014-11-10 12:23                   ` Arnaldo Carvalho de Melo
2014-11-11  6:53                     ` Masami Hiramatsu
2014-11-11 13:10                       ` Arnaldo Carvalho de Melo
2014-11-12 15:26                         ` Masami Hiramatsu
2014-11-17  3:09                           ` Namhyung Kim
2014-11-17  3:17                             ` Masami Hiramatsu
2014-11-17 22:09                               ` Masami Hiramatsu
2014-11-18  4:51                                 ` Namhyung Kim
2014-11-18 11:16                                   ` Masami Hiramatsu
2014-11-18  4:41                               ` Namhyung Kim
2014-11-18 10:32                                 ` Masami Hiramatsu
2014-11-17 18:59                             ` Arnaldo Carvalho de Melo
2014-11-18  4:46                               ` Namhyung Kim
2014-11-10 12:05                 ` Hagen Paul Pfeifer
2014-11-10 12:31                   ` Arnaldo Carvalho de Melo
2014-11-10 12:50                   ` Peter Zijlstra
2014-11-10 13:37                     ` Hagen Paul Pfeifer
2014-11-05 18:24           ` [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events Hemant Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54588905.7040002@linux.vnet.ibm.com \
    --to=hemant@linux.vnet.ibm.com \
    --cc=anton@redhat.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=hegdevasant@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=penberg@iki.fi \
    --cc=peterz@infradead.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).