From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753615AbbFWGcK (ORCPT ); Tue, 23 Jun 2015 02:32:10 -0400 Received: from mga14.intel.com ([192.55.52.115]:64089 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751899AbbFWGcB (ORCPT ); Tue, 23 Jun 2015 02:32:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,664,1427785200"; d="scan'208";a="732764530" Message-ID: <5588FCCE.8090403@intel.com> Date: Tue, 23 Jun 2015 09:29:34 +0300 From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo CC: Ingo Molnar , linux-kernel@vger.kernel.org, Jiri Olsa Subject: Re: [PATCH V6 08/17] perf tools: Add Intel PT support 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> <20150622230005.GA8510@kernel.org> In-Reply-To: <20150622230005.GA8510@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/