Messages in this thread | | | Date | Wed, 18 Mar 2015 16:14:06 +0900 | From | Namhyung Kim <> | Subject | Re: [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
| |