Messages in this thread | | | Date | Mon, 17 Aug 2015 20:43:09 +0300 | From | Adrian Hunter <> | Subject | Re: [PATCH V8 08/25] perf tools: Add Intel BTS support |
| |
On 17/08/2015 6:52 p.m., Arnaldo Carvalho de Melo wrote: > Em Fri, Jul 17, 2015 at 07:33:43PM +0300, Adrian Hunter escreveu: >> Intel BTS support fits within the new auxtrace infrastructure. >> Recording is supporting by identifying the Intel BTS PMU, parsing >> options and setting up events. >> >> Decoding is supported by queuing up trace data by thread and then >> decoding synchronously delivering synthesized event samples into the >> session processing for tools to consume. > > So, I am not being able to reproduce the results from last time I tried > it.. > > [root@zoo ~]# uname -r > 4.2.0-rc5+ > > But all the DSOs are not being resolved :-\ Same machine, will try after lunch > with a tip/master built kernel, right now I get this, perhaps that "81649 > instruction errors" message? I'll see what are the results with tip/master, > meanwhile what I have is at the tmp.perf/intel_pt branch in my tree. > > - Arnaldo > > [root@zoo ~]# perf record --per-thread -e intel_bts// usleep 1 > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 1.884 MB perf.data ] > [root@zoo ~]# perf evlist > intel_bts// > dummy:u > [root@zoo ~]# perf evlist -v > intel_bts//: type: 6, size: 112, { sample_period, sample_freq }: 1, > sample_type: IP|TID|IDENTIFIER, read_format: ID, disabled: 1, > enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 > dummy:u: type: 1, size: 112, config: 0x9, { sample_period, sample_freq > }: 1, sample_type: IP|TID|IDENTIFIER, read_format: ID, disabled: 1, > exclude_kernel: 1, exclude_hv: 1, mmap: 1, comm: 1, enable_on_exec: 1, > task: 1, sample_id_all: 1, mmap2: 1, comm_exec: 1 > [root@zoo ~]# > > Warning: > 81649 instruction trace errors > # To display the perf.data header info, please use --header/--header-only options. > # > # > # Total Lost Samples: 0 > # > # Samples: 0 of event 'intel_bts//' > # 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: 81K of event 'branches' > # Event count (approx.): 81649 > # > # Overhead Command Shared Object Symbol > # ........ ....... ................ ...................... > # > 2.71% usleep [unknown] [.] 0x00007fa0ff695061 > 2.62% usleep [unknown] [.] 0x00007fa0ffb3de7e > 1.96% usleep [unknown] [.] 0x00007fa0ffb2e726 > 1.92% usleep [unknown] [.] 0x00007fa0ff695086 > 1.60% usleep [unknown] [.] 0xffffffff811c91d0 > 1.48% usleep [unknown] [.] 0x00007fa0ffb3030d > 1.24% usleep [unknown] [.] 0x00007fa0ff6950c7 > > > >
It is very weird that it doesn't know the dso.
I presume there is nothing unusual about the environment e.g. in a chroot or anything
What if you try a different event e.g. perf record --per-thread -e cycles sleep 1
| |