From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756767AbdKDN0J (ORCPT ); Sat, 4 Nov 2017 09:26:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35300 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752103AbdKDN0H (ORCPT ); Sat, 4 Nov 2017 09:26:07 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DFEE05D685 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jolsa@redhat.com Date: Sat, 4 Nov 2017 14:25:56 +0100 From: Jiri Olsa To: Megha Dey Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, andriy.shevchenko@linux.intel.com, kstewart@linuxfoundation.org, yu-cheng.yu@intel.com, len.brown@intel.com, gregkh@linuxfoundation.org, peterz@infradead.org, acme@kernel.org, alexander.shishkin@linux.intel.com, namhyung@kernel.org, vikas.shivappa@linux.intel.com, pombredanne@nexb.com, me@kylehuey.com, bp@suse.de, grzegorz.andrejczuk@intel.com, tony.luck@intel.com, corbet@lwn.net, ravi.v.shankar@intel.com, megha.dey@intel.com Subject: Re: [PATCH V0 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support Message-ID: <20171104132556.GD8454@krava> References: <1509732006-5917-1-git-send-email-megha.dey@linux.intel.com> <1509732006-5917-3-git-send-email-megha.dey@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1509732006-5917-3-git-send-email-megha.dey@linux.intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Sat, 04 Nov 2017 13:26:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 03, 2017 at 11:00:05AM -0700, Megha Dey wrote: SNIP > +static unsigned int bm_threshold = BM_MAX_THRESHOLD; > +static unsigned int bm_mispred_evt_cnt; > + > +/* Branch monitoring counter owners */ > +static struct perf_event *bm_counter_owner[2]; SNIP > + * Find a hardware counter for the target task > + */ > + for (i = 0; i < bm_num_counters; i++) { > + if ((bm_counter_owner[i] == NULL) || > + (bm_counter_owner[i]->state == PERF_EVENT_STATE_DEAD)) { > + counter_to_use = i; > + bm_counter_owner[i] = event; > + break; > + } > + } > + > + if (counter_to_use == -1) > + return -EBUSY; not sure I understand, your docs says: "There are 2 8-bit counters that each.. " so there are 2 counters per CPU? if that's corrent, isn't this check too strict then? you could have more events configured running on other CPUs for another tasks given that we do task only events here, should bm_counter_owner be part of task, together with the limit..? I'm probably missing something.. thanks, jirka