The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Hemant Kumar <hemant@linux.vnet.ibm.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-kernel@vger.kernel.org, acme@kernel.org,
	peterz@infradead.org, namhyung@kernel.org, mingo@redhat.com,
	ananth@linux.vnet.ibm.com
Subject: Re: [PATCH] perf/sdt: Directly record cached SDT events
Date: Wed, 04 May 2016 02:48:01 +0530	[thread overview]
Message-ID: <57291589.2040302@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160503093526.12bd508cd8df8b09197c5100@kernel.org>



On 05/03/2016 06:05 AM, Masami Hiramatsu wrote:
> On Tue, 03 May 2016 05:06:24 +0530
> Hemant Kumar <hemant@linux.vnet.ibm.com> wrote:
>
>> Hi Masami,
>>
>> On 04/30/2016 06:06 PM, Masami Hiramatsu wrote:
>>> Hi Hemant,
>>>
>>> On Fri, 29 Apr 2016 19:10:41 +0530
>>> Hemant Kumar <hemant@linux.vnet.ibm.com> wrote:
>>>
>>>> This patch adds support for directly recording SDT events which are
>>>> present in the probe cache. This patch is based on current SDT
>>>> enablement patchset (v5) by Masami :
>>>> https://lkml.org/lkml/2016/4/27/828
>>>> and it implements two points in the TODO list mentioned in the
>>>> cover note :
>>>> "- (perf record) Support SDT event recording directly"
>>>> "- (perf record) Try to unregister SDT events after record."
>>>>
>>>> Without this patch, we could probe into SDT events using
>>>> "perf probe" and "perf record". With this patch, we can probe
>>>> the SDT events directly using "perf record".
>>> Thanks! However, before looking over each part of this patch,
>>> I think this is not enough for supporting SDT for perf record.
>> Hmm.
>>
>>> If there are several SDTs which have same eventname but differnt
>>> addresses (e.g. libc:memory_memalign_retry), how are those handled?
>>> Currently, to support this, we'll need to enable those events
>>> in different names, or just pick one of them. It could confuse
>>> users in each case.
>> Right. But now, its the same case with a binary having multiple
>> symbols with same names, isn't it?
> Yes, but for the symbols or lines etc., user can not directly specify
> it via perf record. And as you showed below, perf-probe expresses
> there are 2 events on the probe point. So user is forced to aware of it.

Right.

>> # nm ./multi | grep foo
>> 0000000000400530 t foo
>> 0000000000400560 t foo
>>
>> # perf probe -x ./multi foo
>> Added new events:
>>     probe_multi:foo      (on foo in /home/hemant/work/linux/tools/perf/multi)
>>     probe_multi:foo_1    (on foo in /home/hemant/work/linux/tools/perf/multi)
>>
>> You can now use it in all perf tools, such as:
>>
>>       perf record -e probe_multi:foo_1 -aR sleep 1
>>
>>
>> My point being, the user can still know, if its shown that there are two or
>> more probes being placed and the o/p of perf report/script shows that
>> the probes are placed at two or more different addresses.
> Not only the different address, but also they will see the different
> event names. That may be no good for making a script on it.
>
> My point is, if the user only uses "perf record -e sdt_something:sdtevent",
> they will think that there is one event recorded. it can easily misleading
> them.

Ok. Makes sense. With a warning message then, we can make the user
aware in this case.

>>> To solve this issue, we need to introduce multiple SDTs on single
>>> ftrace event. Please read my comment on v3 patch (https://lkml.org/lkml/2015/8/15/52)
>> Ok. But, I think, for initial direct recording support, we can go with
>> this IMHO.
> So, at least this should be noticed to users carefully. (e.g. warn if
> there are more than two SDTs defined)

Ok. I have made the changes and also added a warning message if the
user tries to record on an sdt event, which has multiple occurences with
the same event and group name. I have sent a v2 for this patch.

-- 
Thanks,
Hemant Kumar

  reply	other threads:[~2016-05-03 21:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 13:40 [PATCH] perf/sdt: Directly record cached SDT events Hemant Kumar
2016-04-30 12:36 ` Masami Hiramatsu
2016-05-02 23:36   ` Hemant Kumar
2016-05-03  0:35     ` Masami Hiramatsu
2016-05-03 21:18       ` Hemant Kumar [this message]
2016-05-02 18:19 ` Brendan Gregg
2016-05-03  0:25   ` Masami Hiramatsu

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=57291589.2040302@linux.vnet.ibm.com \
    --to=hemant@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.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