lkml.org 
[lkml]   [2015]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V6 08/17] perf tools: Add Intel PT support
On 23/06/15 02:00, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 22, 2015 at 11:26:34PM +0300, Adrian Hunter escreveu:
>> On 22/06/2015 9:24 p.m., Arnaldo Carvalho de Melo wrote:
>>> Em Fri, Jun 19, 2015 at 04:41:56PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Fri, Jun 19, 2015 at 10:33:43PM +0300, Adrian Hunter escreveu:
>>>>> On 19/06/2015 7:04 p.m., Arnaldo Carvalho de Melo wrote:
>>>>>> Em Fri, May 29, 2015 at 04:33:36PM +0300, Adrian Hunter escreveu:
>>>>>>> Add support for Intel Processor Trace.
>>>>
>>>>>>> Intel PT support fits within the new auxtrace infrastructure.
>>>>>>> Recording is supporting by identifying the Intel PT PMU,
>>>>>>> parsing options and setting up events. Decoding is supported
>>>>>>> by queuing up trace data by cpu or thread and then decoding
>>>>>>> synchronously delivering synthesized event samples into the
>>>>>>> session processing for tools to consume.
>>>>
>>>>>> So, at this point what commands should I use to test this? I expected to
>>>>>> be able to have some command here, in this changeset log, telling me
>>>>>> that what has been applied so far + this "Add Intel PT support", can be
>>>>>> used in such and such a fashion, obtaining this and that output.
>>>>
>>>>>> Now I'll go back and look at the cover letter to see what I can do at
>>>>>> this point and with access to a Broadwell class machine.
>>>>
>>>>> Actually you need the next patch "perf tools: Take Intel PT into use" to do anything.
>>>>
>>>> Yeah, saw that, the title of this patch fooled me into thinking that
>>>> Intel PT support was added :-)
>>>>
>>>> Anyway, stopping for a moment to push stuff ready to Ingo, will get back
>>>> to this after that.
>>>
>>> So, got back to it, added that "take it into use" patch and now trying
>>> to follow that documentation:
>>>
>>> [root@perf4 ~]# perf evlist
>>> intel_pt//u
>>> sched:sched_switch
>>> dummy:u
>>> [root@perf4 ~]# perf report
>>> [root@perf4 ~]# perf record -e intel_pt//u -a sleep 10
>>> [ perf record: Woken up 1 times to write data ]
>>> [ perf record: Captured and wrote 0.379 MB perf.data ]
>>> [root@perf4 ~]#
>>> [root@perf4 ~]#
>>> [root@perf4 ~]# perf report
>>> [root@perf4 ~]# perf evlist
>>> intel_pt//u
>>> sched:sched_switch
>>> dummy:u
>>> [root@perf4 ~]# uname -r
>>> 4.1.0-rc8
>>> [root@perf4 ~]#
>>>
>>> I am not getting any "intel_pt//u" event, ideas?
>>
>> Events are synthesized by the decoder. You should see 'instructions:u' events.
>>
>> What does perf report --stdio give?
>
> Well, away from a Broadwell machine now, applied a few patches more and
> I'm now trying BTS, on this Ivy Bridge notebook (MacBook Air):
>
> [ 0.000000] DMI: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B02.1211271028 11/27/2012
>
> [ 0.116644] perf_event_intel: PMU erratum BJ122, BV98, HSD29 worked around, HT is on
>
> [ 0.061626] TSC deadline timer enabled
> [ 0.061630] smpboot: CPU0: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz (fam: 06, model: 3a, stepping: 09)
> [ 0.061661] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, full-width counters, Intel PMU driver.
> [ 0.061685] ... version: 3
> [ 0.061686] ... bit width: 48
> [ 0.061687] ... generic registers: 4
> [ 0.061688] ... value mask: 0000ffffffffffff
> [ 0.061690] ... max period: 0000ffffffffffff
> [ 0.061691] ... fixed-purpose events: 3
> [ 0.061692] ... event mask: 000000070000000f
> [ 0.062587] x86: Booting SMP configuration:
> [ 0.062589] .... node #0, CPUs: #1
> [ 0.074078] microcode: CPU1 microcode updated early to revision 0x1b, date = 2014-05-29
> [ 0.076715] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
> [ 0.076825] #2 #3
> [ 0.104559] x86: Booted up 1 node, 4 CPUs
> [ 0.104563] smpboot: Total of 4 processors activated (19953.49 BogoMIPS)
>
> [root@zoo ~]# perf record -e intel_bts//u --per-thread sleep 5
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.531 MB perf.data ]
> [root@zoo ~]# perf evlist
> intel_bts//u
> dummy:u
> [root@zoo ~]#
>
> [root@zoo ~]# perf report --stdio | head -40
> # To display the perf.data header info, please use --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 0 of event 'intel_bts//u'
> # Event count (approx.): 0
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... ............. ......
> #
>
>
> # Samples: 0 of event 'dummy:u'
> # Event count (approx.): 0
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... ............. ......
> #
>
>
> # Samples: 22K of event 'branches:u'
> # Event count (approx.): 22548
> #
> # Overhead Command Shared Object Symbol
> # ........ ....... ................ ......................
> #
> 9.82% sleep [unknown] [.] 0x00007f8e86c09061
> 8.28% sleep [unknown] [.] 0x00007f8e86ea4e7e
> 6.97% sleep [unknown] [.] 0x00007f8e86c09086
> 5.88% sleep [unknown] [.] 0x00007f8e86e95726
> 5.28% sleep [unknown] [.] 0x00007f8e86e9730d
> 4.69% sleep [unknown] [.] 0x00007f8e86b06bc1
> 4.48% sleep [unknown] [.] 0x00007f8e86c090c7
> 4.01% sleep [unknown] [.] 0x00007f8e86c09027
> 4.01% sleep [unknown] [.] 0x00007f8e86c0904c
> 2.84% sleep [unknown] [.] 0x00007f8e86c0908c
> 2.74% sleep [unknown] [.] 0x00007f8e86c0909d
> 2.74% sleep [unknown] [.] 0x00007f8e86c09037
> 1.20% sleep [unknown] [.] 0x00007f8e86af9c68
>
> -----------------------------------------------------------------
>
> Ok, so it synthesized the branches:u, that don't appear on the 'perf evlist'
> output, that is the command I use to see what kinds of events are contained
> in a given perf.data file, probably we should add a note there that
> branches:u will be synthesized at 'report' time, trying with 'perf script':
>
> [root@zoo ~]# perf script | head -10
> :8676 8676 1 branches:u: ffffffff81799b47 [unknown] ([unknown]) => 7f8e86e8bcf0 [unknown] ([unknown])
> :8676 8676 1 branches:u: ffffffff81799b47 [unknown] ([unknown]) => 7f8e86e8bcf0 [unknown] ([unknown])
> :8676 8676 1 branches:u: 7f8e86e8bcf3 [unknown] ([unknown]) => 7f8e86e8f980 [unknown] ([unknown])
> :8676 8676 1 branches:u: ffffffff81799b47 [unknown] ([unknown]) => 7f8e86e8f9a6 [unknown] ([unknown])
> :8676 8676 1 branches:u: 7f8e86e8fa11 [unknown] ([unknown]) => 7f8e86e8fa2f [unknown] ([unknown])
> :8676 8676 1 branches:u: 7f8e86e8fa33 [unknown] ([unknown]) => 7f8e86e8fa18 [unknown] ([unknown])
> :8676 8676 1 branches:u: 7f8e86e8fa33 [unknown] ([unknown]) => 7f8e86e8fa18 [unknown] ([unknown])
> :8676 8676 1 branches:u: 7f8e86e8fa3f [unknown] ([unknown]) => 7f8e86e8fc18 [unknown] ([unknown])
> :8676 8676 1 branches:u: 7f8e86e8fc20 [unknown] ([unknown]) => 7f8e86e8fc40 [unknown] ([unknown])
>
> The synthesized records looks sane:
>
> [root@zoo ~]# perf report -D | grep PERF_RECORD_ | tail -15
> 0x36f8 [0x78]: PERF_RECORD_MMAP -1/0: [0xffffffffa0933000(0x5000) @ 0]: x /lib/modules/4.1.0-rc5+/kernel/net/netfilter/xt_CHECKSUM.ko
> 0x3770 [0x68]: PERF_RECORD_MMAP -1/0: [0xffffffffa0938000(0x18000) @ 0]: x /lib/modules/4.1.0-rc5+/kernel/fs/fuse/fuse.ko
> 0x37d8 [0x68]: PERF_RECORD_MMAP -1/0: [0xffffffffa0950000(0x5f6affff) @ 0]: x /lib/modules/4.1.0-rc5+/kernel/crypto/ccm.ko
> 0x3840 [0x20]: PERF_RECORD_ITRACE_START pid: 8676 tid: 8676
> 0x3860 [0x28]: PERF_RECORD_COMM exec: sleep:8676/8676
> 0x3888 [0x68]: PERF_RECORD_MMAP2 8676/8676: [0x400000(0x6000) @ 0 fd:01 525758 1481335351]: r-xp /usr/bin/sleep
> 0x38f0 [0x70]: PERF_RECORD_MMAP2 8676/8676: [0x7f8e86e8b000(0x224000) @ 0 fd:01 534148 868528687]: r-xp /usr/lib64/ld-2.20.so
> 0x3960 [0x60]: PERF_RECORD_MMAP2 8676/8676: [0x7ffdc21d4000(0x2000) @ 0x7ffdc21d4000 00:00 0 0]: ---p [vdso]
> 0x39c0 [0x70]: PERF_RECORD_MMAP2 8676/8676: [0x7f8e86ace000(0x3bd000) @ 0 fd:01 531160 868528694]: r-xp /usr/lib64/libc-2.20.so
> 0x3a30 [0x30]: PERF_RECORD_AUX offset: 0 size: 0x80688 flags: 0 []
> 0x3a60 [0x30]: PERF_RECORD_EXIT(8676:8676):(8676:8676)
> 0x3a90 [0x30]: PERF_RECORD_AUX offset: 0x80688 size: 0x3b70 flags: 0 []
> 0x3ac0 [0x30]: PERF_RECORD_EXIT(8676:8676):(8676:8676)
> 0x3af0 [0x30]: PERF_RECORD_AUXTRACE size: 0x841f8 offset: 0 ref: 0x531e5c6921c idx: 0 tid: 8676 cpu: -1
> 0x87d18 [0x8]: PERF_RECORD_FINISHED_ROUNDAggregated stats: (excludes AUX area (e.g. instruction trace) decoded / synthesized events)
> [root@zoo ~]#
>
> One of those samples
>
>>>> (0x7f8e86e8fa3f - 0x7f8e86ace000) < 0x3bd000
> False
>
> After the libc-2.20.so map
>
>>>> (0x7f8e86e8fa3f - 0x7f8e86e8b000) < 0x224000
> True
>
> Ok, so a /usr/lib64/ld-2.20.so sample, and:
>
> [root@zoo ~]# rpm -q glibc-debuginfo
> glibc-debuginfo-2.20-8.fc21.x86_64
>
> But then, it didn't even resolve the DSO, which it should, as I did manually :-/
>
> Will continue investigating... Perhaps this is fixed in another patch? What I
> have test merged so far is at my tmp.perf/pt branch.

I tried the same commands with perf tools from that branch (tmp.perf/pt) and
it seemed to work fine.

One reason for not getting symbols is compiling perf tools without ELF support.

>
> I will still update the cset comments and possibly do some other changes to
> preserve bisectability or some other fix so that we get more test output
> inserted in the changesets.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2015-06-23 09:01    [W:0.121 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site