From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755124AbbCRHTZ (ORCPT ); Wed, 18 Mar 2015 03:19:25 -0400 Received: from lgeamrelo04.lge.com ([156.147.1.127]:49058 "EHLO lgeamrelo04.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755067AbbCRHTV (ORCPT ); Wed, 18 Mar 2015 03:19:21 -0400 X-Original-SENDERIP: 10.177.220.203 X-Original-MAILFROM: namhyung@kernel.org Date: Wed, 18 Mar 2015 16:14:06 +0900 From: Namhyung Kim To: Andi Kleen Cc: "Liang, Kan" , "acme@kernel.org" , "linux-kernel@vger.kernel.org" , "eranian@google.com" , jolsa@kernel.org Subject: Re: [PATCH 1/1] perf, tool: partial callgrap and time support in perf record Message-ID: <20150318071406.GS943@sejong> References: <1426213087-25593-1-git-send-email-kan.liang@intel.com> <20150316020348.GO943@sejong> <37D7C6CF3E00A74B8858931C1DB2F07701751D32@SHSMSX103.ccr.corp.intel.com> <20150316204826.GK31334@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150316204826.GK31334@tassilo.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > > > > > > 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