From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757418AbbJVMg7 (ORCPT ); Thu, 22 Oct 2015 08:36:59 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:33911 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754435AbbJVMg6 (ORCPT ); Thu, 22 Oct 2015 08:36:58 -0400 MIME-Version: 1.0 In-Reply-To: <20151022084655.GA19913@gmail.com> References: <1444079018-31421-1-git-send-email-acme@kernel.org> <1444079018-31421-14-git-send-email-acme@kernel.org> <56264040.20708@huawei.com> <20151020133816.GD4400@redhat.com> <20151021084816.GA12992@gmail.com> <20151021134348.GI10639@kernel.org> <20151022084655.GA19913@gmail.com> From: Namhyung Kim Date: Thu, 22 Oct 2015 21:36:37 +0900 X-Google-Sender-Auth: A-lP0_XWK3mVl4zZKYhdqZk8Afc Message-ID: Subject: Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller' To: Ingo Molnar Cc: Arnaldo Carvalho de Melo , "Wangnan (F)" , "linux-kernel@vger.kernel.org" , Adrian Hunter , Borislav Petkov , Chandler Carruth , David Ahern , Frederic Weisbecker , Jiri Olsa , Stephane Eranian , pi3orama Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 22, 2015 at 5:46 PM, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > >> > 5) --no-children >> > >> > I agree that 'perf top -g --no-children' looks more intuitive than 'perf top -g'. >> >> So, what do you propose, to switch back the default to --no-children, for both >> tools, top and report? Now that I am getting used to it... ;-) > > Heh ;-) So I'm only thinking out loud, trying to find the most intuitive initial > screen to display. Expert users can configure their output any which way they want > it to be, I'm not worried about them. :) > > It's casual and in particular first-time users we should be worried about most - > if they try the '-g' option in record, what will they first see in 'perf report' > output? > > I think the best output method would be to include only the 'highest level' parent > symbols, with all children summed up under the parent's entry. Isn't the new > 'graph,0.5,caller' default very close to that? Hmm.. not sure I'm following well. what do you mean by 'highest level parent'? Do you want single depth callchains for each entry? > > But what confuses me about the output is the same that confused Wangnan's users: > > "This is my story: after switching to new version of perf, in a period of time > there are plenty of perf users in my company be confused by the first column of > 'perf report' because the sum of the percentage listed there is much higher than > 100%. They find me because they think this is a bug in perf which breaks their > routinely profiling work." > > So this is suboptimal. > > The first column is 'Children', which should show the sum of all child overhead - > but if a child overhead was already included under a parent, it should never show > up under another parent's entry. I.e. the first column should only contain the > highest level entries, no sub-entries. Again, I don't understand. Could you elaborate it more probably with example below? > > But what we do currently is: > > Children Self Command Shared Object Symbol > - 70.41% 0.00% cc1 cc1 [.] toplev_main > - toplev_main > + __libc_start_main > - 70.38% 0.00% cc1 libc-2.20.so [.] __libc_start_main > + __libc_start_main > > i.e. even though '__libc_start_main' is a child of 'toplev_main', it's still > included on the 'overview' page. Strange. AFAIK 'toplev_main' is a child of '__libc_start_main'. Are you using 'caller' ordering? Also I think 'main' should be shown between 'toplev_main' and '__libc_start_main' but maybe it's a different issue. Thanks, Namhyung > > Is there an output method that can do what I suggest above? > > ( Having both 'children' and 'self' columns in itself is intuitive IMHO: it shows > that an entry that is shown does not directly have overhead at that level, a > child call of it has that overhead. ) > > Thanks, > > Ingo