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

[Ingo Molnar <mingo@kernel.org>]

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> On Wed, Nov 06, 2013 at 09:30:46AM +0100, Ingo Molnar wrote:
> > 
> > * Namhyung Kim <namhyung@kernel.org> wrote:
> > 
> > > Hi Ingo,
> > > 
> > > On Tue, 5 Nov 2013 12:58:02 +0100, Ingo Molnar wrote:
> > > > * Namhyung Kim <namhyung@kernel.org> wrote:
> > > >> But the 'cumulative' (btw, I feel a bit hard to type this word..) is 
> > > >> different in that it *generates* entries didn't get sampled originally. 
> > > >> And as it requires callchains, total field will not work if callchains 
> > > >> are missing.
> > > >
> > > > Well, 'total' should disappear if it's not available.
> > > 
> > > But what if it's the only sort key user gave?
> > 
> > Do you mean something like:
> > 
> >   -F self,name -s total
> > 
> > i.e. if a sort key not displayed?
> > 
> > I think sort keys should be automatically added to the displayed fields 
> > list.
> > 
> > This rule is obviously met with the -F total:2,self:1,name:0 kind of 
> > sorting syntax (you can only sort by fields that get displayed) - if 
> > mixed with -s then it should be implicit I think.
> 
> I'm not sure why you want to add a new -F that adds news way to display 
> fields. Isn't -s enough for that?

Well, -s implies sorting.

With -F we could decouple sorting from display order, and allow output 
like:

  # Symbol   Command    Shared Object   Overhead

Where we still sort by 'overhead', yet display things by having 'overhead' 
last.

So basically have maximum flexibility of output and sorting - into which 
the new 'total' field for accumulated stats would fit automatically.

Thanks,

	Ingo