All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	Hemant Kumar <hkshaw@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>,
	hegdevasant@linux.vnet.ibm.com, Ingo Molnar <mingo@redhat.com>,
	anton@redhat.com, systemtap@sourceware.org,
	Namhyung Kim <namhyung@kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	aravinda@linux.vnet.ibm.com
Subject: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
Date: Sat, 26 Oct 2013 11:50:23 +0200	[thread overview]
Message-ID: <20131026095023.GF14237@gmail.com> (raw)
In-Reply-To: <20131025125921.GA29424@linux.vnet.ibm.com>


* Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:

> Hi Pekka,
> 
> > >
> > > You can now use it in all perf tools, such as:
> > >
> > >     perf record -e libc:my_event -aR sleep 1
> > 
> > Is there a technical reason why 'perf list' could not show all the
> > available SDT markers on a system and that the 'market to event'
> > mapping cannot happen automatically?
> > 
> 
> Technically feasible. But then we would have to parse each of the 
> libraries and executables to list them. Right? I am not sure if 
> such a delay is acceptable.

I'd say lets try Pekka's suggestion and make it more palatable if 
there's complaints about the delay. (SSD systems are becoming 
dominant and there the search should be reasonably fast.)

We could also make 'perf list' more sophisticated, if invoked 
naively as 'perf list' then maybe it should first display the 
various event categories, with a (rough) count:

$ perf list
   34 hardware events       # use 'perf list --hw'    to list them
   40 hw-cache events       # use 'perf list --cache' to list them
   20 software events       # use 'perf list --sw'    to list them
    2 raw events            # use 'perf list --raw'   to list them
  120 tracepoints           # use 'perf list --tp'    to list them
  >10 SDT tracepoints       # use 'perf list --sdt'   to list them

 # use 'perf list -a' to list all events
 # use 'perf list ./binary' to list events in a given binary

I.e. bring a bit more structure into it.

> Also if a binary exists in a path thats is not covered in the 
> default search, an user might believe that his binary may not have 
> markers. I know the above reason is more of a user folly than a 
> tooling issue.

I think in 99% of the usecases people will either use pre-built 
markers that come with their distro, or will be intimately aware of 
the markers because they are in the very app they are developing.

So I wouldn't worry about 'user has a weird binary' case too much.

I agree with Pekka that making them easily discoverable and visible 
as a coherent whole is really important.

Thanks,

	Ingo

  parent reply	other threads:[~2013-10-26  9:50 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23  5:04 [PATCH v4 0/3] perf support to SDT markers Hemant Kumar
2013-10-23  5:04 ` [PATCH v4 1/3] SDT markers listing by perf: Hemant Kumar
2013-10-23  5:05 ` [PATCH v4 2/3] Support for perf to probe into SDT markers: Hemant Kumar
2013-10-24  5:45   ` Masami Hiramatsu
2013-10-24 10:25     ` Hemant Kumar
2013-10-25 12:38   ` Pekka Enberg
2013-10-25 12:59     ` Srikar Dronamraju
2013-10-25 14:20       ` Pekka Enberg
2013-10-25 15:20         ` David Ahern
2013-10-28  8:48           ` Pekka Enberg
2013-10-28 16:59             ` David Ahern
2013-10-28 18:45               ` Pekka Enberg
2013-10-29  9:55                 ` Hemant Kumar
2013-10-29 14:05                   ` Pekka Enberg
2013-10-29 19:41                     ` Hemant Kumar
2013-10-30 10:22                 ` Masami Hiramatsu
2013-10-26  9:50       ` Ingo Molnar [this message]
2013-10-28  8:56         ` Pekka Enberg
2013-10-28 10:57         ` Masami Hiramatsu
2013-10-29  5:50         ` Namhyung Kim
2013-10-26 11:16     ` Frank Ch. Eigler
2013-10-28  8:40       ` Pekka Enberg
2013-10-28 10:34         ` Ingo Molnar
2013-10-30 10:05       ` Masami Hiramatsu
2013-10-30 11:51         ` Pekka Enberg
2013-10-31  9:59           ` Ingo Molnar
2013-10-31 10:54           ` Mark Wielaard
2013-10-31 10:57             ` Ingo Molnar
2013-10-31 13:12               ` Peter Zijlstra
2013-10-31 13:23               ` Mark Wielaard
2013-10-30 13:30         ` Hemant Kumar
2013-10-28 11:23     ` Masami Hiramatsu
2013-10-28 12:42       ` Pekka Enberg
2013-10-28 14:11         ` Srikar Dronamraju
2013-10-28 14:21           ` Pekka Enberg
2013-10-28 17:31             ` Srikar Dronamraju
2013-10-28 17:48               ` Pekka Enberg
2013-10-29  3:19                 ` Masami Hiramatsu
2013-10-29  5:31                   ` Namhyung Kim
2013-10-29 14:51                   ` Mark Wielaard
2013-10-29 19:54                     ` Pekka Enberg
2013-10-29  2:51               ` Masami Hiramatsu
2013-10-23  5:05 ` [PATCH v4 3/3] Documentation regarding perf/sdt 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=20131026095023.GF14237@gmail.com \
    --to=mingo@kernel.org \
    --cc=anton@redhat.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=hegdevasant@linux.vnet.ibm.com \
    --cc=hkshaw@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@kernel.org \
    --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.