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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A7BC5FC.2070905@inria.fr>
Date:	Fri, 07 Aug 2009 08:13:16 +0200
From:	Brice Goglin <Brice.Goglin@...ia.fr>
To:	unlisted-recipients:; (no To-header on input)
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, paulus@...ba.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] perf tools: Fix reading of perf.data file header

Brice Goglin wrote:
> Ingo Molnar wrote:
>   
>> It would be nice to add this as some "perf report -s/--stats" flag, 
>> to not have to go via -D (which is a 'print debug output' kind of 
>> ad-hoc thing and subject to format changes in the future).
>>
>> Would you be interested in sending a patch that adds that flag to 
>> 'perf report', to print out these statistics entries (if any), in a 
>> tabular form suitable for your purposes? Below is a past patch to 
>> builtin-report.c that shows how to add new options.
>>   
>>     
>
> Here's a quick'n'dirty first try. Read events are copied in the
> show_stat_event array during process_read_event. And __cmd_report sorts
> the array by tid before displaying it.
>
> perf report -S now shows the following after the existing output: (-s is
> already used for something else).
> It shows things like
> # Per-thread statistics:
> # PID    TID       Event          Count
>   16709   16709   cache-misses   82727
>   16709   16709   cache-references   41238768
>   16709   16710   cache-misses   6462
>   16709   16710   cache-references   76119375
> or
> # Per-thread statistics:
> # PID    TID       Event          Count
>   6268   6268   raw 0x1000001e0   494628
>   6268   6268   raw 0x1000002e0   209113
>   6268   6268   raw 0x1000004e0   307215
>   6268   6268   raw 0x1000008e0   9203221
>   6268   6269   raw 0x1000001e0   9210788
>   6268   6269   raw 0x1000002e0   302344
>   6268   6269   raw 0x1000004e0   198705
>   6268   6269   raw 0x1000008e0   473471
>
> Obviously, there's some a lot of nice pretty printing to do, but you'll
> be able to tell whether the general idea is ok or not.
>   


Is there an easy way to know how many threads and how many different
event types were recorded? Once I know that, I could directly gather
values into a 2D matrix and display a single line per thread with all
corresponding event counter (so that people can easily apply awk to
manipulate them).

I am adding some pretty printing to the previous patch and waiting for
your feedback (for instance, what kind of global variable names, command
line option names, ... do you want or so).

Brice

PS: Is there a perf counters mailing list?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ