From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753305AbbJUBom (ORCPT ); Tue, 20 Oct 2015 21:44:42 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:34616 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752998AbbJUBok (ORCPT ); Tue, 20 Oct 2015 21:44:40 -0400 Date: Wed, 21 Oct 2015 10:44:32 +0900 From: Namhyung Kim To: Arnaldo Carvalho de Melo Cc: "Wangnan (F)" , Arnaldo Carvalho de Melo , Ingo Molnar , linux-kernel@vger.kernel.org, Adrian Hunter , Borislav Petkov , Chandler Carruth , David Ahern , Frederic Weisbecker , Jiri Olsa , Stephane Eranian , pi3orama Subject: Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller' Message-ID: <20151021014432.GB628@sejong> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151020133816.GD4400@redhat.com> 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 Tue, Oct 20, 2015 at 11:38:16AM -0200, Arnaldo Carvalho de Melo wrote: > Em Tue, Oct 20, 2015 at 09:23:12PM +0800, Wangnan (F) escreveu: > > On 2015/10/6 5:03, Arnaldo Carvalho de Melo wrote: > > >From: Arnaldo Carvalho de Melo > > >Which is the most common default found in other similar tools. > > > Could you please show me some example about "other similar tools"? > > For me, in most of the case I prefer callee order because most of my > > task is to explain the reason why some code get executed too much times > > than expected. > > > Also, I think changing default settings should be careful. > > > 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. The > > "problem" is caused by the adding of "--children". New perf makes > > '--children' as the default behavior at the first time it support that > > option, but the old perf shows things similar to '--no-children'. > > However, it is hard to explain the principle of call stack accumulation > > and why we need '--children' to those perf users (they learned perf's > > command line from others, and don't have enought to read perf > > documentations or even help output. Althought the title of the first > > column is changed to 'Children', I don't think they can understand the > > meaning of it. I think some of them didn't even notice there's an > > addition column in their output. They just confused and angry). Also, > > and as you can expect, this change breaks some scripts. In those days I > > have to make our IM tool response the information of "--no-children" > > automatically. > > > > This patch changes the default output again. Similar thing will happen > > another time. I think this time I can make some preparation, for example, > > prepare new script to restore old behavior? > > I was bitten by the --children thing and took some time to get used to > it, so I can relate to that... I feel sorry about that. I did worry about the existing users when making the --children default and actually I didn't agree with making it default at first. :-( > > I think we should revert this change in callchain default, enough > complaints... Ingo, since you suggested that change, what are your > thoughts? > > Changing defaults is hard, there is also the horizontal scrolling that > made we repurpose the right and left arrows, sigh, that one will cause > some confusion as well... Yeah, it worries me too. That's why I used '<' and '>' key for scrolling in my patch. Maybe it's worth adding those keys again, reverting arrows key actions, and show some message that it'll be changed later? > > It seems we'll need way more preparation for such changes, more > infrastructure to ease the transition, questioning if the user wants > that, etc, growing pains :-\ Yes, it reminds me of changing default push behavior in git 2.0. We need to provide info and wait for enough time before changing some behavior IMHO. Thanks, Namhyung