mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	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,
	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: Tue, 29 Oct 2013 14:50:07 +0900	[thread overview]
Message-ID: <8738nk7hio.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <20131026095023.GF14237@gmail.com> (Ingo Molnar's message of "Sat, 26 Oct 2013 11:50:23 +0200")

Hi Ingo,

On Sat, 26 Oct 2013 11:50:23 +0200, Ingo Molnar wrote:
> * 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.

I like this. :)

Note that 'perf list' already support this kind of filtering now:

  $ perf list hw cache sw tracepoint pmu

or

  $ perf list sched:*

It'd be great if this globbing also supports SDTs.

And for 'perf list ./binary' case, it could detect libraries in the
dependency list and then also scan them.

>
>> 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.

Agreed.  We do need to improve the user experience of the perf tools!

Thanks,
Namhyung

  parent reply	other threads:[~2013-10-29  5: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
2013-10-28  8:56         ` Pekka Enberg
2013-10-28 10:57         ` Masami Hiramatsu
2013-10-29  5:50         ` Namhyung Kim [this message]
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=8738nk7hio.fsf@sejong.aot.lge.com \
    --to=namhyung@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@kernel.org \
    --cc=mingo@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome