From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753315AbcAVLiB (ORCPT ); Fri, 22 Jan 2016 06:38:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57913 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752730AbcAVLhy (ORCPT ); Fri, 22 Jan 2016 06:37:54 -0500 Date: Fri, 22 Jan 2016 12:37:49 +0100 From: Jiri Olsa To: Namhyung Kim Cc: Arnaldo Carvalho de Melo , Ingo Molnar , Peter Zijlstra , Jiri Olsa , LKML , David Ahern , Stephane Eranian , Andi Kleen , Wang Nan Subject: Re: [PATCH 01/17] perf hists: Basic support of hierarchical report view Message-ID: <20160122113749.GA2306@krava.brq.redhat.com> References: <1452960197-5323-1-git-send-email-namhyung@kernel.org> <1452960197-5323-2-git-send-email-namhyung@kernel.org> <20160121104330.GD13547@krava.brq.redhat.com> <20160121125552.GA13893@danjae.kornet> <20160121133558.GC11238@krava.brq.redhat.com> <20160122104312.GA8942@danjae.kornet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160122104312.GA8942@danjae.kornet> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 22, 2016 at 07:43:12PM +0900, Namhyung Kim wrote: > 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. ok, I took the collapsing as a part of resort > > > > > > 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 ok, sounds good.. maybe we could use some other name for collapsing then.. like build,setup or such thanks for bearing with me ;-) jirka