linux-kernel - Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160122104312.GA8942@danjae.kornet>
Date:	Fri, 22 Jan 2016 19:43:12 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Jiri Olsa <jolsa@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Wang Nan <wangnan0@...wei.com>
Subject: Re: [PATCH 01/17] perf hists: Basic support of hierarchical report
 view

Hi Jiri,

On Thu, Jan 21, 2016 at 02:35:58PM +0100, Jiri Olsa wrote:
> On Thu, Jan 21, 2016 at 09:55:52PM +0900, Namhyung Kim wrote:
> > > would it make more sense to do this in 'in-tree addition' path?
> > > and keep the resort functions to do only resort stuff
> > 
> > I don't follow.  There're 3 path to handle hist entries - let's say
> > them as 'addition', 'collapsing', and 'resort'.  This function does
> > the 'collapsing' part - it was originally intended to merge sharable
> > entries (namely for same 'comm' among different threads).  But I used
> > it to build a hierarchy since I found it useful as follows:
> > 
> >   1. it requires smaller change than doing it in the 'addition' path
> >   2. it can reuse current callback-based 'addition' paths so mem- and
> >      branch-mode can be supported easily (but it needs test..).
> >   3. the 'addition' path can be parallelized so it'll increase memory
> >      footprint if it build temporary local hierarchies during the path.
> > 
> > The 'resort' path always do sorting only..
> 
> well, you are adding/duplicating entries now in resort path
> and that is not just 'sorting only'

As I said, this is not the 'resort' path, the 'resort' path is the
subject of patch 02/17.


> 
> you allow only sort and tracepoint entries to be added in
> hierrarych view, so there's no resort needed, but still it
> could be added in future? not sure

Resorting is still needed since it should sort entries by overhead
(period).  Anyway, in this 'collapsing' path, we need to build a
hierarchy to be sorted at the resort path.


> 
> it still makes more sense to me to do this in 'addition' path,
> because you basically add new entries
> 
> but have no other grounds for this also I might be missing something ;-)

What about thinking like this?

1. addition   - add samples into hist entries
2. collapsing - build complete hists (hierarchy) to be sorted
3. resort     - sort final entries based on the sort keys

Thanks,
Namhyung