linux-kernel - Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8738nk7hio.fsf@sejong.aot.lge.com>
Date:	Tue, 29 Oct 2013 14:50:07 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Pekka Enberg <penberg@...nel.org>,
	Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Oleg Nesterov <oleg@...hat.com>,
	hegdevasant@...ux.vnet.ibm.com, Ingo Molnar <mingo@...hat.com>,
	anton@...hat.com, systemtap@...rceware.org,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	aravinda@...ux.vnet.ibm.com
Subject: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:

Hi Ingo,

On Sat, 26 Oct 2013 11:50:23 +0200, Ingo Molnar wrote:
> * Srikar Dronamraju <srikar@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/