Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754745AbcC3QA0 (ORCPT ); Wed, 30 Mar 2016 12:00:26 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:33303 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754592AbcC3QAY (ORCPT ); Wed, 30 Mar 2016 12:00:24 -0400 Date: Thu, 31 Mar 2016 01:00:10 +0900 From: Namhyung Kim To: Andres Freund Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: "perf hists browser: Support flat callchains" appears to have broken parent reporting Message-ID: <20160330160010.GA1557@danjae> References: <20160330123418.GC12336@awork2.anarazel.de> <20160330134634.GA3420@kernel.org> <20160330141926.GA5242@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160330141926.GA5242@awork2.anarazel.de> 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 Content-Length: 2159 Lines: 61 Hi Andres, On Wed, Mar 30, 2016 at 04:19:26PM +0200, Andres Freund wrote: > On 2016-03-30 10:46:34 -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Mar 30, 2016 at 02:34:18PM +0200, Andres Freund escreveu: > > > Hi, > > > > > > 4b3a3212233a - "perf hists browser: Support flat callchains" seems to > > > have broken callchain display in tui mode when using !flat mode, or at > > > least changed it in an unintended manner. > > > > humm, at first I thought this would be related to --percent-limit... > > I'm not using --percent-limit. Just to be sure, I did explicitly set it > to various values, and it looks unrelated. > > > What tree/branch are you using? Can you try pressing 'L' to play with > > the percent limit? > > I'm primarily using linus' tree, and bisected the behavioural down to > that individual commit. Thanks for reporting and finding this! > > It's somewhat weird that --stdio doesn't show the problem, but --tui > does. Hm. > > > I don't know the perf code at all, but skimming through the commit, the > following hunk looks suspicious: > > @@ -263,7 +295,7 @@ static void callchain_node__init_have_children(struct callchain_node *node, > chain = list_entry(node->val.next, struct callchain_list, list); > chain->has_children = has_sibling; > > - if (!list_empty(&node->val)) { > + if (node->val.next != node->val.prev) { > chain = list_entry(node->val.prev, struct callchain_list, list); > chain->has_children = !RB_EMPTY_ROOT(&node->rb_root); > } > > Reverting that individual change fixes things. I'm not actually sure > what the post 4b3a3212233a version actually tests for? Yeah, this is it. It's my fault that I thought if the first chain (node->val.next) was set by has_sibling, no need to go to the body of the "if" statement when next == prev case. But it's not... > > > I think that actually explains why stdio works - nodes are always > unfolded in it, thus ->has_children isn't looked at. Right, the ->has_children thing is only for TUI code which folds/collapses the entries dynamically. Do you mind resending the fix as a formal patch with my ack ? Thanks, Namhyung