All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Stephane Eranian <eranian@google.com>,
	namhyung.kim@lge.com
Subject: Re: [PATCH 1/4] perf hists: Exchange order of comparing items when collapsing hists
Date: Wed, 12 Dec 2012 16:56:32 +0100	[thread overview]
Message-ID: <20121212155632.GA1097@krava.brq.redhat.com> (raw)
In-Reply-To: <20121212152926.GA2382@ghostprotocols.net>

On Wed, Dec 12, 2012 at 12:29:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 10, 2012 at 02:44:34PM +0100, Jiri Olsa escreveu:
> > On Mon, Dec 10, 2012 at 05:29:54PM +0900, Namhyung Kim wrote:
> > > When comparing entries for collapsing put the given entry first, and then
> > > the iterated entry.  This is not the case of hist_entry__cmp() when called
> > > if given sort keys don't require collapsing.  So change the order for the
> > > sake of consistency.  It will be required for matching and/or linking
> > > multiple hist entries.
> 
> > Acked-by: Jiri Olsa <jolsa@redhat.com>
> 
> Hey,
> 
> Before:
> 
> [root@sandy ~]# perf diff
> # Event 'cycles'
> #
> # Baseline    Delta      Shared Object                              Symbol
> # ........  .......  .................  ..................................
> #
>     17.41%  -17.41%  [kernel.kallsyms]  [k] memset                        
>      0.38%   -0.38%  [kernel.kallsyms]  [k] strlcpy                       
>             +48.19%  [kernel.kallsyms]  [k] __blocking_notifier_call_chain
>             +46.96%  [kernel.kallsyms]  [k] radix_tree_lookup_slot        
>              +4.66%  [kernel.kallsyms]  [k] do_close_on_exec              
>     16.17%  -16.17%  [kernel.kallsyms]  [k] final_putname                 
>      4.17%   -4.17%  [kernel.kallsyms]  [k] shift_arg_pages               
>     30.74%  -30.74%  [kernel.kallsyms]  [k] kfree                         
>     14.93%  -14.93%  [kernel.kallsyms]  [k] unlock_page                   
>      0.03%   +0.15%  [kernel.kallsyms]  [k] native_write_msr_safe         
>     16.17%  -16.17%  libc-2.12.so       [.] _dl_addr                      
> 
> After:
> 
> [root@sandy ~]# perf diff
> # Event 'cycles'
> #
> # Baseline    Delta      Shared Object                              Symbol
> # ........  .......  .................  ..................................
> #
>     16.17%  -16.17%  libc-2.12.so       [.] _dl_addr                      
>             +48.19%  [kernel.kallsyms]  [k] __blocking_notifier_call_chain
>     14.93%  -14.93%  [kernel.kallsyms]  [k] unlock_page                   
>     30.74%  -30.74%  [kernel.kallsyms]  [k] kfree                         
>      4.17%   -4.17%  [kernel.kallsyms]  [k] shift_arg_pages               
>     16.17%  -16.17%  [kernel.kallsyms]  [k] final_putname                 
>             +46.96%  [kernel.kallsyms]  [k] radix_tree_lookup_slot        
>              +4.66%  [kernel.kallsyms]  [k] do_close_on_exec              
>      0.03%   +0.15%  [kernel.kallsyms]  [k] native_write_msr_safe         
>      0.38%   -0.38%  [kernel.kallsyms]  [k] strlcpy                       
>     17.41%  -17.41%  [kernel.kallsyms]  [k] memset                        
> [root@sandy ~]#
> 
> Got inverted.
> 
> The order was arbitrary, and was arbitrarily reversed, are you guys sure this
> is the only side effect?

right,

currently (without namhyung's changes) there's initial 'name' sorting
broken by hists_link

after the change, it gets sorted 'but' there are dummy entries added
which brake the sort again.. this is sorted out within the multi diff
patches

so the bottom line is that currently the sorting is broken anyway,
and the fix is comming in upcomming patchset ;)

> 
> Jiri, IIRC you mentioned that there would be some patch with an --order switch,
> would that allow sorting by the entry that had the biggest change, etc?

by default it'll sorted by baseline and you can specify -o X to sort
by specified file

thanks,
jirka

  reply	other threads:[~2012-12-12 15:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10  8:29 [PATCH 0/4] perf hists: Changes on hists__{match,link} (v4) Namhyung Kim
2012-12-10  8:29 ` [PATCH 1/4] perf hists: Exchange order of comparing items when collapsing hists Namhyung Kim
2012-12-10 13:44   ` Jiri Olsa
2012-12-12 15:29     ` Arnaldo Carvalho de Melo
2012-12-12 15:56       ` Jiri Olsa [this message]
2012-12-12 16:14         ` Arnaldo Carvalho de Melo
2013-01-25 10:47   ` [tip:perf/core] " tip-bot for Namhyung Kim
2012-12-10  8:29 ` [PATCH 2/4] perf hists: Link hist entries before inserting to an output tree Namhyung Kim
2013-01-25 10:48   ` [tip:perf/core] " tip-bot for Namhyung Kim
2012-12-10  8:29 ` [PATCH 3/4] perf diff: Use internal rb tree for compute resort Namhyung Kim
2013-01-25 10:49   ` [tip:perf/core] " tip-bot for Namhyung Kim
2012-12-10  8:29 ` [PATCH 4/4] perf test: Add a test case for hists__{match,link} Namhyung Kim
2013-01-25 10:51   ` [tip:perf/core] perf test: Add a test case for hists__{match, link} tip-bot for Namhyung Kim

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=20121212155632.GA1097@krava.brq.redhat.com \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung.kim@lge.com \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.