Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754117AbbHUNYS (ORCPT ); Fri, 21 Aug 2015 09:24:18 -0400 Received: from mga09.intel.com ([134.134.136.24]:47631 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751647AbbHUNYR convert rfc822-to-8bit (ORCPT ); Fri, 21 Aug 2015 09:24:17 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,721,1432623600"; d="scan'208";a="773115265" From: "Liang, Kan" To: Jiri Olsa CC: "acme@kernel.org" , "a.p.zijlstra@chello.nl" , "mingo@redhat.com" , "jolsa@kernel.org" , "namhyung@kernel.org" , "ak@linux.intel.com" , "eranian@google.com" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH RFC 01/10] perf,tools: open event on evsel cpus and threads Thread-Topic: [PATCH RFC 01/10] perf,tools: open event on evsel cpus and threads Thread-Index: AQHQ2dS6LRSkpWsTW0yysdp+sUOU154UErwAgAEPTxCAAG5GAIAA4umA Date: Fri, 21 Aug 2015 13:24:09 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018EFA5F@SHSMSX103.ccr.corp.intel.com> References: <1439889946-28986-1-git-send-email-kan.liang@intel.com> <1439889946-28986-2-git-send-email-kan.liang@intel.com> <20150820085734.GA1672@krava.brq.redhat.com> <37D7C6CF3E00A74B8858931C1DB2F077018EF7A2@SHSMSX103.ccr.corp.intel.com> <20150821074318.GA20546@krava> In-Reply-To: <20150821074318.GA20546@krava> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3071 Lines: 94 > > On Thu, Aug 20, 2015 at 05:24:32PM +0000, Liang, Kan wrote: > > > > > > On Tue, Aug 18, 2015 at 05:25:37AM -0400, kan.liang@intel.com wrote: > > > > From: Kan Liang > > > > > > > > evsel may have different cpus and threads as evlist's. > > > > Use it's own cpus and threads, when open evsel in perf record. > > > > > > > > Signed-off-by: Kan Liang > > > > --- > > > > tools/perf/builtin-record.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/tools/perf/builtin-record.c > > > > b/tools/perf/builtin-record.c index 25cf6b4..a0178bf 100644 > > > > --- a/tools/perf/builtin-record.c > > > > +++ b/tools/perf/builtin-record.c > > > > @@ -279,7 +279,7 @@ static int record__open(struct record *rec) > > > > > > > > evlist__for_each(evlist, pos) { > > > > try_again: > > > > - if (perf_evsel__open(pos, evlist->cpus, evlist->threads) < > > > 0) { > > > > + if (perf_evsel__open(pos, pos->cpus, pos->threads) < 0) { > > > > if (perf_evsel__fallback(pos, errno, msg, > > > sizeof(msg))) { > > > > if (verbose) > > > > ui__warning("%s\n", msg); > > > > -- > > > > 1.8.3.1 > > > > > > > > > > dont we need then handle filters the same way? > > > like in attached change? totally untested.. > > > > Filters look only work for tracepoint event, which doesn't have cpu limit. > > So evlist and evsel should always be same. > > I think we don't need to change it. > > right.. at least please make a comment about that > OK. I will do that. > > > > > > > > jirka > > > > > > > > > --- > > > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c > > > index 7aa039bd379a..f5cdf678d504 100644 > > > --- a/tools/perf/builtin-stat.c > > > +++ b/tools/perf/builtin-stat.c > > > @@ -244,12 +244,9 @@ static void handle_initial_delay(void) > > > struct perf_evsel *counter; > > > > > > if (initial_delay) { > > > - const int ncpus = cpu_map__nr(evsel_list->cpus), > > > - nthreads = thread_map__nr(evsel_list->threads); > > > - > > > usleep(initial_delay * 1000); > > > evlist__for_each(evsel_list, counter) > > > - perf_evsel__enable(counter, ncpus, nthreads); > > > + perf_evsel__enable(counter); > > > } > > > } > > > > > > > Agree, we need to use evsel's cpu and threads here. > > What about the code as below? It should be simpler. > > + perf_evsel__enable(counter, > cpu_map__nr(counter->cpus), > > +thread_map__nr(counter->threads)); > > > > ok, maybe I'll submit that patch as a cleanup, it seems more sane to use > evsel cpus and threads now that we always have it there > I guess I will send out the builtin-record change and comments as a patch. So you can either merge the cleanup code to that patch, or send out the cleanup patch separately. Either is fine for me. Thanks, Kan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/