linux-kernel - Re: [PATCH] perf script: Print callchains and symbols if they exist

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: <528CC2A2.6000403@gmail.com>
Date:	Wed, 20 Nov 2013 07:09:38 -0700
From:	David Ahern <dsahern@...il.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	acme@...stprotocols.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf script: Print callchains and symbols if they exist
 - v2

On 11/20/13, 6:04 AM, Frederic Weisbecker wrote:

> We probably want to avoid DSO and IP for most tracepoints. For kernel
> tracepoints dso is going to be the kernel anyway and IP is often not that relevant
> either.

Sorry, you mentioned that last time and I forgot to respond.

Yes, there are a number of tracepoints that are completely kernel side 
and possibly uninteresting callstacks. There are others that are 
triggered in process context and you want to see the stacks all the way 
back to main. I would hope that users are adding -g to record only when 
it is truly wanted. Given that the idea of perf-script is to print data 
in a file why not dump everything in the file - address, dso, and 
symbol. There is always -G to suppress the callchains.

As an example it is useful to see the overhead of 'perf sched record 
-g': all I really want is callchains on sched_switch, and the callchains 
on sched_stat_runtime and wakeup are huge emphasizing the need to 
specify events where callchains are interesting and not collect them on 
others and that steps into the pandora's box of mixed sample types.

David

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