linux-kernel - Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Nov 2013 08:46:50 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Namhyung Kim <namhyung.kim@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Stephane Eranian <eranian@...gle.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Rodrigo Campos <rodrigo@...g.com.ar>,
	Arun Sharma <asharma@...com>
Subject: Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist
 periods (v2)


* Namhyung Kim <namhyung@...nel.org> wrote:

> Hi Ingo,
> 
> On Fri, 1 Nov 2013 10:27:59 +0100, Ingo Molnar wrote:
> > * Namhyung Kim <namhyung@...nel.org> wrote:
> >
> >> >> > 2)
> >> >> >
> >> >> > Is it possible to configure the default 'report -g' style, so that 
> >> >> > people who'd like to use it all the time don't have to type '-g 
> >> >> > cumulative' all the time?
> >> >> 
> >> >> Hmm.. maybe I can add support for the 'report.call-graph' config option.
> >> >
> >> > If we display your new 'total' field by default then it's not as 
> >> > pressing to me :)
> >> 
> >> Do you mean -g cumulative without 'self' column?
> >
> > So, if by default we display both 'self' and 'total' and sort by 
> > 'total', then I'm personally a happy camper: while it's a change of 
> > the default perf report output, it's also a step forward.
> >
> > But some people might complain about it once this hits v3.13 (or 
> > v3.14) and might want to hide individual columns and have different 
> > sorting preferences.
> >
> > So out of defensive caution you might want to provide toggles for 
> > such things, maybe even generalize it a bit to allow arbitrary 
> > hiding/display of individual colums in perf report.
> >
> > That would probably also make it easier to do minimal tweaks to the 
> > upstream reporting defaults.
> 
> Okay, so what would the interface look like?
> 
> I think it'd better to separate the option and pass column and
> (optional) sort key argument.
> 
>   --cumulative both,total (default)
>   --cumulative both,self
>   --cumulative total
>   --cumulative self (meaningless?)
> 
> Maybe we need a config option and a single letter option for the default
> case like --call-graph and -g options do.
> 
> What do you think?

So why restrict it to 'cumulative'? Why not have a generic --fields/-F, 
with a good default. The ordering of the fields determines sorting 
behavior.

The default would be something like:

  -F total,self,process,dso,name

Whether 'cumulative' data is calculated is not a function of any direct 
option, but simply a function of whether the 'total' field is in the -F 
list of columns displayed or not.

With that scheme we could also do things like this to get old-style 
sorting:

 -F self,process,dso,name

Or a really frugal 'readprofile'-style output:

 -F self,name

if one is only interested in percentages and raw function names.

Wrt. sorting order, by default the first column in the list of columns 
would be the primary (and only) sort key.

(The -F field setup list could also be specified in the .perfconfig.)

With this method we could do away with all this geometrical explosion of 
somewhat inconsistent formatting and sorting options...

If there's demand then we could decouple sort keys from the display order, 
by slightly augmenting the field format:

 -F total,self:2,process:0,dso:1,name

This would sort by 'process' field as the primary key, 'dso' the secondary 
key and 'self' as the tertiary key.

And we could also keep the -s/--sort option:

 -s process,dso,self

So the above -F line would be equivalent to:

 -F total,self,process,dso,name -s process,dso,self

What do you think?

Thanks,

	Ingo
--
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/