All of lore.kernel.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 13:36:29 +0530	[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: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 10:53 [PATCH v4 0/5] perf/sdt: SDT events listing/probing Hemant Kumar
2014-11-02 10:54 ` [PATCH v4 1/5] perf/sdt: ELF support for SDT Hemant Kumar
2014-11-02 10:54 ` [PATCH v4 2/5] perf/sdt: Add SDT events into a cache Hemant Kumar
2014-11-02 10:55 ` [PATCH v4 3/5] perf/sdt: Show SDT cache contents Hemant Kumar
2014-11-02 10:55 ` [PATCH v4 4/5] perf/sdt: Delete SDT events from cache Hemant Kumar
2014-11-02 10:56 ` [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:56       ` Masami Hiramatsu
     [not found]         ` <5459BD3E.7010804@linux.vnet.ibm.com>
2014-11-05  6:50           ` 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:15             ` Josh Stone
2014-11-06  5:33               ` 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:57                   ` [PATCH RESEND 1/2] perf tools: Move disable_buildid_cache() to util/build-id.c Namhyung Kim
2014-11-07 13:57                     ` [PATCH 2/2] perf tools: Add record.use-buildid-cache config option Namhyung Kim
2014-11-20  7:36                     ` [tip:perf/core] perf build-id: Move disable_buildid_cache() to util/build-id.c tip-bot for 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:25                         ` Masami Hiramatsu
2014-11-17  3:08                           ` 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:58                             ` Arnaldo Carvalho de Melo
2014-11-18  4:45                               ` 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:23           ` [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.