From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753555AbbFVXA2 (ORCPT ); Mon, 22 Jun 2015 19:00:28 -0400 Received: from mail.kernel.org ([198.145.29.136]:37306 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751511AbbFVXAU (ORCPT ); Mon, 22 Jun 2015 19:00:20 -0400 Date: Mon, 22 Jun 2015 20:00:05 -0300 From: Arnaldo Carvalho de Melo To: Adrian Hunter Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Jiri Olsa Subject: Re: [PATCH V6 08/17] perf tools: Add Intel PT support Message-ID: <20150622230005.GA8510@kernel.org> References: <1432906425-9911-1-git-send-email-adrian.hunter@intel.com> <1432906425-9911-9-git-send-email-adrian.hunter@intel.com> <20150619160451.GM3079@kernel.org> <55846E97.3050705@intel.com> <20150619194156.GE31188@kernel.org> <20150622182444.GI13937@kernel.org> <55886F7A.30702@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55886F7A.30702@intel.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/