From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752710AbbI0T5J (ORCPT ); Sun, 27 Sep 2015 15:57:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39425 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750957AbbI0T5H (ORCPT ); Sun, 27 Sep 2015 15:57:07 -0400 Date: Sun, 27 Sep 2015 21:57:00 +0200 From: Jiri Olsa To: "Liang, Kan" Cc: "acme@kernel.org" , "jolsa@kernel.org" , "a.p.zijlstra@chello.nl" , "mingo@redhat.com" , "namhyung@kernel.org" , "ak@linux.intel.com" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC 00/10] counter read during perf sampling Message-ID: <20150927195700.GD24007@krava.redhat.com> References: <1442931223-51708-1-git-send-email-kan.liang@intel.com> <20150924081912.GE2024@krava.redhat.com> <37D7C6CF3E00A74B8858931C1DB2F07701941815@shsmsx102.ccr.corp.intel.com> <20150924222806.GA21290@krava.redhat.com> <37D7C6CF3E00A74B8858931C1DB2F07701941C44@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F07701941C44@shsmsx102.ccr.corp.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 On Fri, Sep 25, 2015 at 02:57:14PM +0000, Liang, Kan wrote: SNIP > > > > > > Yes, the way to store the data from perf stat is better than pure > > > script way. I guess your patch "perf stat record" can do that, right? > > > > > > If so, how should we run perf record and stat in parallel? By scripts > > > or modify perf record/stat? > > > > > > Also, we need an option in perf report to merge the perf.data-s. Right? > > > > either that or extra step with 'perf data merge' or somthing like that > > > > Any update about "perf stat record" patch set? That will help a lot, if I'll try to post new version this week > we finally choose the 'perf data merge' way. Right? I think we could do both ways.. let user choose whatever is more convenient SNIP > > > > the way I see it you implemented 'perf stat' logic within record command > > you create counter (non sampling) and read it via read syscall > > > > I think it's good idea, but I think we should follow the way we do in perf > > stat command and reuse the interface (and code) > > > > like having the 'stat' keyword separating the non-sampling config: > > > > $ perf record -e cycles stat -e 'uncore_imc_1/cas_count_read/' -I 10000 - > > ./tchain_edit > > > > Another thing is that there is limitation for --interval-print in perf stat. > The interval must >= 100ms. However, we need the interval >=10ms. > > Any idea about where 100ms is from? Print limit? I don't recall any reason for this limitation, IMO it was just convenient to have higher unit because lower wasn't needed.. so I think we can change it do 10ms SNIP > > > > hum, how the --counter-read-interval data displayed then? it's not single > > number right? > > > No matter which way we choose, I think the output should be similar. > > As my original design, perf only output every --counter-read-interval data > in perf report -D. > For tui and stdio, it only output the aggregate number. So, yes, single number. > > I think it should be enough. In tui/stdio, perf gives user a roughly image by > the total number during the whole sampling process. If they want details, > they can check by report -D. > Considering the interval is only 10ms, if perf output everything in tui/stdio, > the output is too huge. what is the reason to read the counter multiple times if you display only single number at the end? overflow issues? thanks, jirka