public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Jin Yao <yao.jin@linux.intel.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
Subject: Re: [PATCH v6 0/7] perf diff: diff cycles at basic block level
Date: Fri, 28 Jun 2019 10:02:55 +0200	[thread overview]
Message-ID: <20190628080255.GA3427@krava> (raw)
In-Reply-To: <1561713784-30533-1-git-send-email-yao.jin@linux.intel.com>

On Fri, Jun 28, 2019 at 05:22:57PM +0800, Jin Yao wrote:
> In some cases small changes in hot loops can show big differences.
> But it's difficult to identify these differences.
> 
> perf diff currently can only diff symbols (functions). We can also expand
> it to diff cycles of individual programs blocks as reported by timed LBR.
> This would allow to identify changes in specific code accurately.
> 
> With this patch set, for example,
> 
>  $ perf record -b ./div
>  $ perf record -b ./div
>  $ perf diff -c cycles
> 
>  # Event 'cycles'
>  #
>  # Baseline                                       [Program Block Range] Cycles Diff  Shared Object     Symbol
>  # ........  ......................................................................  ................  ..................................
>  #
>      48.75%                                             [div.c:42 -> div.c:45]  147  div               [.] main
>      48.75%                                             [div.c:31 -> div.c:40]    4  div               [.] main
>      48.75%                                             [div.c:40 -> div.c:40]    0  div               [.] main
>      48.75%                                             [div.c:42 -> div.c:42]    0  div               [.] main
>      48.75%                                             [div.c:42 -> div.c:44]    0  div               [.] main
>      19.02%                                 [random_r.c:357 -> random_r.c:360]    0  libc-2.23.so      [.] __random_r
>      19.02%                                 [random_r.c:357 -> random_r.c:373]    0  libc-2.23.so      [.] __random_r
>      19.02%                                 [random_r.c:357 -> random_r.c:376]    0  libc-2.23.so      [.] __random_r
>      19.02%                                 [random_r.c:357 -> random_r.c:380]    0  libc-2.23.so      [.] __random_r
>      19.02%                                 [random_r.c:357 -> random_r.c:392]    0  libc-2.23.so      [.] __random_r
>      16.17%                                     [random.c:288 -> random.c:291]    0  libc-2.23.so      [.] __random
>      16.17%                                     [random.c:288 -> random.c:291]    0  libc-2.23.so      [.] __random
>      16.17%                                     [random.c:288 -> random.c:295]    0  libc-2.23.so      [.] __random
>      16.17%                                     [random.c:288 -> random.c:297]    0  libc-2.23.so      [.] __random
>      16.17%                                     [random.c:291 -> random.c:291]    0  libc-2.23.so      [.] __random
>      16.17%                                     [random.c:293 -> random.c:293]    0  libc-2.23.so      [.] __random
>       8.21%                                             [div.c:22 -> div.c:22]  148  div               [.] compute_flag
>       8.21%                                             [div.c:22 -> div.c:25]    0  div               [.] compute_flag
>       8.21%                                             [div.c:27 -> div.c:28]    0  div               [.] compute_flag
>       5.52%                                           [rand.c:26 -> rand.c:27]    0  libc-2.23.so      [.] rand
>       5.52%                                           [rand.c:26 -> rand.c:28]    0  libc-2.23.so      [.] rand
>       2.27%                                         [rand@plt+0 -> rand@plt+0]    0  div               [.] rand@plt
>       0.01%                                 [entry_64.S:694 -> entry_64.S:694]   16  [kernel.vmlinux]  [k] native_irq_return_iret
>       0.00%                                       [fair.c:7676 -> fair.c:7665]  162  [kernel.vmlinux]  [k] update_blocked_averages
> 
>  '[Program Block Range]' indicates the range of program basic block
>  (start -> end). If we can find the source line it prints the source
>  line otherwise it prints the symbol+offset instead.
> 
>  v6:
>  ---
>  Remove the 'ops' argument in hists__add_entry_block. No functional change.
> 
>  Changed patches
>   perf util: Add block_info in hist_entry 
>   perf diff: Use hists to manage basic blocks per symbol

Reviewed-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka

  reply	other threads:[~2019-06-28  8:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28  9:22 [PATCH v6 0/7] perf diff: diff cycles at basic block level Jin Yao
2019-06-28  8:02 ` Jiri Olsa [this message]
2019-07-02 15:51   ` Arnaldo Carvalho de Melo
2019-06-28  9:22 ` [PATCH v6 1/7] perf util: Create block_info structure Jin Yao
2019-07-03 14:32   ` [tip:perf/core] perf symbol: " tip-bot for Jin Yao
2019-06-28  9:22 ` [PATCH v6 2/7] perf util: Add block_info in hist_entry Jin Yao
2019-07-03 14:33   ` [tip:perf/core] perf hists: " tip-bot for Jin Yao
2019-06-28  9:23 ` [PATCH v6 3/7] perf diff: Check if all data files with branch stacks Jin Yao
2019-07-03 14:34   ` [tip:perf/core] " tip-bot for Jin Yao
2019-06-28  9:23 ` [PATCH v6 4/7] perf diff: Use hists to manage basic blocks per symbol Jin Yao
2019-07-03 14:35   ` [tip:perf/core] " tip-bot for Jin Yao
2019-06-28  9:23 ` [PATCH v6 5/7] perf diff: Link same basic blocks among different data Jin Yao
2019-07-02 16:17   ` Arnaldo Carvalho de Melo
2019-07-02 16:20     ` Arnaldo Carvalho de Melo
2019-07-03  1:07       ` Jin, Yao
2019-07-03 14:35   ` [tip:perf/core] " tip-bot for Jin Yao
2019-06-28  9:23 ` [PATCH v6 6/7] perf diff: Print the basic block cycles diff Jin Yao
2019-07-03 14:36   ` [tip:perf/core] " tip-bot for Jin Yao
2019-06-28  9:23 ` [PATCH v6 7/7] perf diff: Documentation -c cycles option Jin Yao
2019-07-03 14:37   ` [tip:perf/core] " tip-bot for Jin Yao

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=20190628080255.GA3427@krava \
    --to=jolsa@redhat.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=kan.liang@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=yao.jin@intel.com \
    --cc=yao.jin@linux.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