linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jin, Yao" <yao.jin@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org,
	mingo@redhat.com, alexander.shishkin@linux.intel.com,
	Linux-kernel@vger.kernel.org, ak@linux.intel.com,
	kan.liang@intel.com, yao.jin@intel.com,
	linuxppc-dev@lists.ozlabs.org, treeze.taeung@gmail.com
Subject: Re: [PATCH v4 0/5] perf report: Show branch type
Date: Thu, 13 Apr 2017 11:25:39 +0800	[thread overview]
Message-ID: <c480d004-8a02-65fb-48b5-6db43b8efa4f@linux.intel.com> (raw)
In-Reply-To: <74ee84f8-e756-65d2-9ba4-b560f6e241bd@linux.intel.com>



On 4/13/2017 10:00 AM, Jin, Yao wrote:
>
>
> On 4/12/2017 6:58 PM, Jiri Olsa wrote:
>> On Wed, Apr 12, 2017 at 06:21:01AM +0800, Jin Yao wrote:
>>
>> SNIP
>>
>>> 3. Use 2 bits in perf_branch_entry for a "cross" metrics checking
>>>     for branch cross 4K or 2M area. It's an approximate computing
>>>     for checking if the branch cross 4K page or 2MB page.
>>>
>>> For example:
>>>
>>> perf record -g --branch-filter any,save_type <command>
>>>
>>> perf report --stdio
>>>
>>>       JCC forward:  27.7%
>>>      JCC backward:   9.8%
>>>               JMP:   0.0%
>>>           IND_JMP:   6.5%
>>>              CALL:  26.6%
>>>          IND_CALL:   0.0%
>>>               RET:  29.3%
>>>              IRET:   0.0%
>>>          CROSS_4K:   0.0%
>>>          CROSS_2M:  14.3%
>> got mangled perf report --stdio output for:
>>
>>
>> [root@ibm-x3650m4-02 perf]# ./perf record -j any,save_type kill
>> kill: not enough arguments
>> [ perf record: Woken up 1 times to write data ]
>> [ perf record: Captured and wrote 0.013 MB perf.data (18 samples) ]
>>
>> [root@ibm-x3650m4-02 perf]# ./perf report --stdio -f | head -30
>> # To display the perf.data header info, please use 
>> --header/--header-only options.
>> #
>> #
>> # Total Lost Samples: 0
>> #
>> # Samples: 253  of event 'cycles'
>> # Event count (approx.): 253
>> #
>> # Overhead  Command  Source Shared Object  Source 
>> Symbol                            Target 
>> Symbol                            Basic Block Cycles
>> # ........  .......  .................... 
>> ....................................... 
>> .......................................  ..................
>> #
>>       8.30%  perf
>> Um  [kernel.vmlinux]      [k] __intel_pmu_enable_all.constprop.17  
>> [k] native_write_msr                     -
>>       7.91%  perf
>> Um  [kernel.vmlinux]      [k] intel_pmu_lbr_enable_all             
>> [k] __intel_pmu_enable_all.constprop.17  -
>>       7.91%  perf
>> Um  [kernel.vmlinux]      [k] native_write_msr                     
>> [k] intel_pmu_lbr_enable_all             -
>>       6.32%  kill     libc-2.24.so          [.] 
>> _dl_addr                             [.] 
>> _dl_addr                             -
>>       5.93%  perf
>> Um  [kernel.vmlinux]      [k] perf_iterate_ctx                     
>> [k] perf_iterate_ctx                     -
>>       2.77%  kill     libc-2.24.so          [.] 
>> malloc                               [.] 
>> malloc                               -
>>       1.98%  kill     libc-2.24.so          [.] 
>> _int_malloc                          [.] 
>> _int_malloc                          -
>>       1.58%  kill     [kernel.vmlinux]      [k] 
>> __rb_insert_augmented                [k] 
>> __rb_insert_augmented                -
>>       1.58%  perf
>> Um  [kernel.vmlinux]      [k] perf_event_exec                      
>> [k] perf_event_exec                      -
>>       1.19%  kill     [kernel.vmlinux]      [k] 
>> anon_vma_interval_tree_insert        [k] 
>> anon_vma_interval_tree_insert        -
>>       1.19%  kill     [kernel.vmlinux]      [k] 
>> free_pgd_range                       [k] 
>> free_pgd_range                       -
>>       1.19%  kill     [kernel.vmlinux]      [k] 
>> n_tty_write                          [k] 
>> n_tty_write                          -
>>       1.19%  perf
>> Um  [kernel.vmlinux]      [k] native_sched_clock                   
>> [k] sched_clock                          -
>> ...
>> SNIP
>>
>>
>> jirka
>
> Sorry, I look at this issue at midnight in Shanghai. I misunderstood 
> that the above output was only a mail format issue. Sorry about that.
>
> Now I recheck the output, and yes, the perf report output is mangled. 
> But my patch doesn't touch the associated code.
>
> Anyway I remove my patches, pull the latest update from perf/core 
> branch and run tests to check if its a regression issue. I test on HSW 
> and SKL both.
>
> 1. On HSW.
>
> root@hsw:/tmp# perf record -j any kill
> ...... /* SNIP */
> For more details see kill(1).
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.014 MB perf.data (9 samples) ]
>
> root@hsw:/tmp# perf report --stdio
> # To display the perf.data header info, please use 
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 144  of event 'cycles'
> # Event count (approx.): 144
> #
> # Overhead  Command  Source Shared Object  Source 
> Symbol                    Target Symbol                    Basic Block 
> Cycles
> # ........  .......  .................... 
> ...............................  ............................... 
> ..................
> #
>     10.42%  kill     libc-2.23.so          [.] 
> read_alias_file              [.] read_alias_file              -
>      9.72%  kill     [kernel.vmlinux]      [k] 
> update_load_avg              [k] update_load_avg              -
>      9.03%  perf
> Um  [unknown]             [k] 0000000000000000             [k] 
> 0000000000000000             -
>      8.33%  kill     libc-2.23.so          [.] 
> _int_malloc                  [.] _int_malloc                  -
> ...... /* SNIP */
>      0.69%  kill     [kernel.vmlinux]      [k] 
> _raw_spin_lock               [k] unmap_page_range             -
>      0.69%  perf
> Um  [kernel.vmlinux]      [k] __intel_pmu_enable_all       [k] 
> native_write_msr             -
>      0.69%  perf
> Um  [kernel.vmlinux]      [k] intel_pmu_lbr_enable_all     [k] 
> __intel_pmu_enable_all       -
>      0.69%  perf
> Um  [kernel.vmlinux]      [k] native_write_msr             [k] 
> intel_pmu_lbr_enable_all     -
>
> The issue is still there.
>
> 2. On SKL
>
> root@skl:/tmp# perf record -j any kill
> ...... /* SNIP */
> For more details see kill(1).
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.012 MB perf.data (1 samples) ]
>
> root@skl:/tmp# perf report --stdio
>
> # To display the perf.data header info, please use 
> --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 32  of event 'cycles'
> # Event count (approx.): 32
> #
> # Overhead  Command  Source Shared Object  Source 
> Symbol                 Target Symbol                 Basic Block Cycles
> # ........  .......  .................... 
> ............................  ............................ 
> ..................
> #
>     90.62%  perf
> Um  [unknown]             [k] 0000000000000000          [k] 
> 0000000000000000          -
>      3.12%  perf
> Um  [kernel.vmlinux]      [k] __intel_pmu_enable_all    [k] 
> native_write_msr          11
>      3.12%  perf
> Um  [kernel.vmlinux]      [k] intel_pmu_lbr_enable_all  [k] 
> __intel_pmu_enable_all    4
>      3.12%  perf
> Um  [kernel.vmlinux]      [k] native_write_msr          [k] 
> intel_pmu_lbr_enable_all  -
>
> The issue is there too.
>
> Now it works without my patch and it runs with latest perf/core 
> branch. So it looks like a regression issue.
>
> Thanks
> Jin Yao
>
>

I have tested, the regression issue is happened after this commit:

bdd97ca perf tools: Refactor the code to strip command name with {l,r}trim()

CC to the author for double checking.

Thanks
Jin Yao

>
>
>
>
>
>
>
>
>
>

  reply	other threads:[~2017-04-13  3:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 22:21 [PATCH v4 0/5] perf report: Show branch type Jin Yao
2017-04-11 22:21 ` [PATCH v4 1/5] perf/core: Define the common branch type classification Jin Yao
2017-04-11 22:21 ` [PATCH v4 2/5] perf/x86/intel: Record branch type Jin Yao
2017-04-11 22:21 ` [PATCH v4 3/5] perf record: Create a new option save_type in --branch-filter Jin Yao
2017-04-11 22:21 ` [PATCH v4 4/5] perf report: Show branch type statistics for stdio mode Jin Yao
2017-04-18 18:53   ` Jiri Olsa
2017-04-19  0:53     ` Jin, Yao
2017-04-19  4:11       ` Jin, Yao
2017-04-18 18:53   ` Jiri Olsa
2017-04-19  0:41     ` Jin, Yao
2017-04-11 22:21 ` [PATCH v4 5/5] perf report: Show branch type in callchain entry Jin Yao
2017-04-18 18:53   ` Jiri Olsa
2017-04-19  0:33     ` Jin, Yao
2017-04-18 18:53   ` Jiri Olsa
2017-04-19  0:32     ` Jin, Yao
2017-04-12 10:58 ` [PATCH v4 0/5] perf report: Show branch type Jiri Olsa
2017-04-12 12:25   ` Jin, Yao
2017-04-12 14:26     ` Jiri Olsa
2017-04-12 15:42       ` Jin, Yao
2017-04-12 15:46         ` Jiri Olsa
2017-04-13  2:00   ` Jin, Yao
2017-04-13  3:25     ` Jin, Yao [this message]
2017-04-13  8:26       ` Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c480d004-8a02-65fb-48b5-6db43b8efa4f@linux.intel.com \
    --to=yao.jin@linux.intel.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=treeze.taeung@gmail.com \
    --cc=yao.jin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).