linux-kernel - Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20151021162718.GB19764@lerouge>
Date:	Wed, 21 Oct 2015 18:27:19 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Chandler Carruth <chandlerc@...il.com>
Cc:	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
	Brendan Gregg <brendan.d.gregg@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Borislav Petkov <bp@...e.de>, David Ahern <dsahern@...il.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Stephane Eranian <eranian@...gle.com>,
	Wang Nan <wangnan0@...wei.com>
Subject: Re: [PATCH 13/16] perf callchain: Switch default to
 'graph,0.5,caller'

On Wed, Oct 21, 2015 at 02:21:12AM +0000, Chandler Carruth wrote:
> On Tue, Oct 20, 2015 at 3:06 AM Arnaldo Carvalho de Melo <
> arnaldo.melo@...il.com> wrote:
> 
> > > IMHO changing that order is not a good idea. Unless many users complained
> > > about it.
> >
> > Perhaps there are not that many users of callchains because the default
> > is not what they're used to see?
> >
> > Motivation for the change came from a video from Chandler, that
> > resurfaced the callchain default issue, Chandler?
> >
> 
> So, first and foremost, thanks for fixing some of my gripes about the
> usability of the perf tool, I'm super excited about the changes you're
> making, even if this one isn't among them.
> 
> I think the default of caller vs. callee is probably the hardest judgement
> call to make about the right defaults. I can see it going both ways.
> 
> When profiling my *system*, or a diverse group of programs or tasks, I
> often find callee useful. Were I a kernel developer, I suspect callee would
> be *dramatically* more common than caller.
> 
> For me, what makes the caller view much more frequently desired is that I'm
> usually profiling a fairly isolated application, or benchmark for an
> isolated library. While I always start off with some more system-level
> performance problem, I rarely need a detailed profile to get a reasonable
> idea of what subsystem to stare at, and then I spend days looking at a
> relatively isolated reproduction.

I understand it that way: callee based is good when you look for a specific issue
to resolve and caller based is better when you want an overview of an object.

That makes sense.

> 
> Anyways, for profiling user-land applications, I suspect from my
> conversations with users that "caller" is the more common expectation.

I wonder what would be the result if people were to use callchains that only involve
the user part. Maybe they prefer caller based because they don't care about
the kernel part.

> > What about providing a hotkey, in the tui, to toggle caller/callee
> > views, and another hotkey to save that in ~/.perfconfig so that becomes
> > the new default?
> >
> 
> OMG, being able to toggle between caller and callee in the tui would be
> *awesome*. Regardless of which default you end up with, I'd love to have
> this feature.

Indeed it could be interesting.

I we want that toggling to be fast enough, we need to process both callee and
caller trees on hists processing, and not rebuild the entire tree each time we
toggle (which would be costly). That's fairly possible to do and it might not
even impact much the loading time if we do this in multithread.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/