From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755242AbbJUNqk (ORCPT ); Wed, 21 Oct 2015 09:46:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46110 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752242AbbJUNqi (ORCPT ); Wed, 21 Oct 2015 09:46:38 -0400 Date: Wed, 21 Oct 2015 10:46:35 -0300 From: Arnaldo Carvalho de Melo To: Ingo Molnar Cc: "Wangnan (F)" , linux-kernel@vger.kernel.org, Adrian Hunter , Borislav Petkov , Chandler Carruth , David Ahern , Frederic Weisbecker , Jiri Olsa , Namhyung Kim , Stephane Eranian , pi3orama Subject: Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller' Message-ID: <20151021134634.GJ10639@kernel.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151021134348.GI10639@kernel.org> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, Oct 21, 2015 at 10:43:48AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Oct 21, 2015 at 10:48:16AM +0200, Ingo Molnar escreveu: > > 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... ;-) And for this one, having a hotkey to toggle children/no-children, in 'top', using a big hammer (perhaps the only one possible since we have no perf.data file?) we could just trow away the existing hist_entries, and flip the relevant flag, the new samples would then use the new mode, etc. For 'report' it would involve, at first sight, reprocessing everything, possibly saving some work because we already did symbol resolution, etc, i.e. the struct machine with its threads, etc will be all there. - Arnaldo