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

Ingo Molnar
2013-11-11T12:12:25Z

* 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