lkml.org 
[lkml]   [2015]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] perf, tool: partial callgrap and time support in perf record
Hi Andi,

(Add Jiri to CC)

On Mon, Mar 16, 2015 at 01:48:26PM -0700, Andi Kleen wrote:
> On Mon, Mar 16, 2015 at 08:35:30PM +0000, Liang, Kan wrote:
> > > On Fri, Mar 13, 2015 at 02:18:07AM +0000, kan.liang@intel.com wrote:
> > > > From: Kan Liang <kan.liang@intel.com>
> > > >
> > > > When multiple events are sampled it may not be needed to collect
> > > > callgraphs for all of them. The sample sites are usually nearby, and
> > > > it's enough to collect the callgraphs on a reference event (such as
> > > > precise cycles or precise instructions). Similarly we also don't need
> > > > fine grained time stamps on all events, as it's enough to have time
> > > > stamps on the regular reference events. This patchkit adds the ability
> > > > to turn off callgraphs and time stamps per event. This in term can
> > > > reduce sampling overhead and the size of the perf.data (add some data)
> > >
> > > Have you taken a look into group sampling feature?
> > > (e.g. perf record -e '{ev1,ev2}:S')
> > >
> >
> > I didn't find any issues when running group read.
> > The patch doesn't change the behavior of group read features.
> >
> > Did you observe any issues after applying the patch?
>
> I think Namhyungs questions was if group read can be used
> instead to decrease the data size.

Right!


>
> The answer is no: it solves a different problem. Group read
> is just fine granuality counting. It cannot be used
> to sample for multiple events in parallel.

But group read disables sampling for non-leader events so the number
of total samples should be small, no?

Thanks,
Namhyung


\
 
 \ /
  Last update: 2015-03-18 08:21    [W:0.072 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site