All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
	Jiri Olsa <jolsa@kernel.org>, Borislav Petkov <bp@suse.de>,
	Hemant Kumar <hemant@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH perf/core v2 15/16] perf buildid-cache: Scan and import user SDT events to probe cache
Date: Tue, 21 Jul 2015 00:52:07 +0900	[thread overview]
Message-ID: <20150720155207.GB9265@danjae.kornet> (raw)
In-Reply-To: <55AC68B2.6080905@hitachi.com>

On Mon, Jul 20, 2015 at 12:19:14PM +0900, Masami Hiramatsu wrote:
> On 2015/07/19 19:46, Namhyung Kim wrote:
> > On Wed, Jul 15, 2015 at 06:15:37PM +0900, Masami Hiramatsu wrote:
> >> perf buildid-cache --add <binary> scans given binary and add
> >> the SDT events to probe cache. It is possible to use the cached
> >> SDT events as other cached events (perf probe <provider>:<event>=<event>).
> > 
> > That means lookup the cached SDT events only using event name, right?
> 
> Right,
> 
> > What if same event names are used by more than one providers?
> 
> That's a good discussion point :)
> 
> What I'm thinking is that the real SDT is always prior to other
> cached events. (currently not implemented yet)
>  - if someone gives a same event name, it overwrites previous one.
>  - if someone gives an event name same as existing SDT, it is not
>    cached (or rejected)
>  - if SDT scanned after cached same name events, SDT always overwrites
>    the entry.

I'm thinking about allowing same name for different events.  IMHO it's
possible to have same SDT names for some reason - i.e. having multiple
versions of same program, similar (but different) binaries have same
event names, or even in a single bianry it might have same event names
but different provider names.

In that case, I think perf probe (or record) simply can do the job for
every matching events.

> 
> So, the all SDT events will be treated as fixed events.
> 
> Note that this will be happen if we agree SDT and probe share the
> same namespace :)

Right.

Thanks,
Namhyung


  reply	other threads:[~2015-07-20 15:54 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15  9:13 [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 01/16] perf probe: Simplify __add_probe_trace_events code Masami Hiramatsu
2015-07-21  9:34   ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 02/16] perf probe: Move ftrace probe-event operations to probe-file.c Masami Hiramatsu
2015-07-21  9:35   ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 03/16] perf probe: Use strbuf for making strings in probe-event.c Masami Hiramatsu
2015-07-17  7:42   ` Namhyung Kim
2015-07-17 10:16     ` Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 04/16] perf-buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 05/16] perf buildid: Use SBUILD_ID_SIZE macro Masami Hiramatsu
2015-07-20 18:47   ` Arnaldo Carvalho de Melo
2015-07-21  9:35   ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 06/16] perf buildid: Introduce sysfs/filename__sprintf_build_id Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 07/16] perf: Add lsdir to read a directory Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 08/16] perf-buildid-cache: Use lsdir for looking up buildid caches Masami Hiramatsu
2015-07-15  9:14 ` [RFC PATCH perf/core v2 09/16] perf probe: Add --cache option to cache the probe definitions Masami Hiramatsu
2015-07-15  9:15 ` [RFC PATCH perf/core v2 10/16] perf probe: Use cache entry if possible Masami Hiramatsu
2015-07-15  9:15 ` [RFC PATCH perf/core v2 11/16] perf probe: Show all cached probes Masami Hiramatsu
2015-07-15  9:15 ` [RFC PATCH perf/core v2 12/16] perf probe: Remove caches when --cache is given Masami Hiramatsu
2015-07-15  9:15 ` [RFC PATCH perf/core v2 13/16] perf/sdt: ELF support for SDT Masami Hiramatsu
2015-07-15  9:15 ` [RFC PATCH perf/core v2 14/16] perf probe: Add group name support Masami Hiramatsu
2015-07-19 10:16   ` Namhyung Kim
2015-07-20  4:48     ` Masami Hiramatsu
2015-07-20 15:31       ` Namhyung Kim
2015-07-15  9:15 ` [RFC PATCH perf/core v2 15/16] perf buildid-cache: Scan and import user SDT events to probe cache Masami Hiramatsu
2015-07-19 10:46   ` Namhyung Kim
2015-07-20  3:19     ` Masami Hiramatsu
2015-07-20 15:52       ` Namhyung Kim [this message]
2015-07-21 10:42         ` Masami Hiramatsu
2015-07-15  9:15 ` [RFC PATCH perf/core v2 16/16] perf probe: Accept %sdt and %cached event name Masami Hiramatsu
2015-07-19 10:53   ` Namhyung Kim
2015-07-20  3:03     ` Masami Hiramatsu
2015-07-16  3:13 ` [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support Hemant Kumar
2015-07-17  3:21   ` Masami Hiramatsu
2015-07-19  4:24     ` Namhyung Kim
2015-07-20  5:47       ` Brendan Gregg
2015-07-20 16:20         ` Namhyung Kim
2015-07-21 10:34           ` Masami Hiramatsu
2015-07-22 14:12     ` Hemant Kumar
2015-07-23 13:13       ` Masami Hiramatsu
2015-07-23 14:01         ` Arnaldo Carvalho de Melo
2015-07-23 16:24           ` Masami Hiramatsu
2015-07-23 16:42             ` Arnaldo Carvalho de Melo
2015-07-24  7:55             ` Namhyung Kim
2015-07-24 15:52               ` Arnaldo Carvalho de Melo
2015-07-25  0:51                 ` Masami Hiramatsu
2015-07-27 14:03                 ` Re: " Namhyung Kim
2015-07-27 15:16                   ` Arnaldo Carvalho de Melo
2015-07-28  0:42                     ` Masami Hiramatsu
2015-07-28 13:45                       ` Arnaldo Carvalho de Melo
2015-07-20 18:36 ` Arnaldo Carvalho de Melo
2015-07-20 18:42   ` Arnaldo Carvalho de Melo

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=20150720155207.GB9265@danjae.kornet \
    --to=namhyung@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=bp@suse.de \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.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.