From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935974AbcHJT5W (ORCPT ); Wed, 10 Aug 2016 15:57:22 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:32833 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933767AbcHJT5T (ORCPT ); Wed, 10 Aug 2016 15:57:19 -0400 Date: Wed, 10 Aug 2016 12:52:31 +0200 From: Ingo Molnar To: kan.liang@intel.com Cc: peterz@infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, eranian@google.com, andi@firstfloor.org, Lukasz Odzioba Subject: Re: [PATCH] perf/x86/intel/uncore: correct uncore num_counters Message-ID: <20160810105231.GA14283@gmail.com> References: <1470150902-38587-1-git-send-email-kan.liang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1470150902-38587-1-git-send-email-kan.liang@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * kan.liang@intel.com wrote: > From: Kan Liang > > Some uncore boxes' num_counters for Haswell server and Broadwell server > are not correct. This patch make them consistent with the uncore > document. > > Reported-by: Lukasz Odzioba > Signed-off-by: Kan Liang > --- > arch/x86/events/intel/uncore_snbep.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c > index 824e540..8aee83b 100644 > --- a/arch/x86/events/intel/uncore_snbep.c > +++ b/arch/x86/events/intel/uncore_snbep.c > @@ -2626,7 +2626,7 @@ void hswep_uncore_cpu_init(void) > > static struct intel_uncore_type hswep_uncore_ha = { > .name = "ha", > - .num_counters = 5, > + .num_counters = 4, > .num_boxes = 2, > .perf_ctr_bits = 48, > SNBEP_UNCORE_PCI_COMMON_INIT(), > @@ -2645,7 +2645,7 @@ static struct uncore_event_desc hswep_uncore_imc_events[] = { > > static struct intel_uncore_type hswep_uncore_imc = { > .name = "imc", > - .num_counters = 5, > + .num_counters = 4, > .num_boxes = 8, > .perf_ctr_bits = 48, > .fixed_ctr_bits = 48, > @@ -2691,7 +2691,7 @@ static struct intel_uncore_type hswep_uncore_irp = { > > static struct intel_uncore_type hswep_uncore_qpi = { > .name = "qpi", > - .num_counters = 5, > + .num_counters = 4, > .num_boxes = 3, > .perf_ctr_bits = 48, > .perf_ctr = SNBEP_PCI_PMON_CTR0, > @@ -2773,7 +2773,7 @@ static struct event_constraint hswep_uncore_r3qpi_constraints[] = { > > static struct intel_uncore_type hswep_uncore_r3qpi = { > .name = "r3qpi", > - .num_counters = 4, > + .num_counters = 3, > .num_boxes = 3, > .perf_ctr_bits = 44, > .constraints = hswep_uncore_r3qpi_constraints, > @@ -2972,7 +2972,7 @@ static struct intel_uncore_type bdx_uncore_ha = { > > static struct intel_uncore_type bdx_uncore_imc = { > .name = "imc", > - .num_counters = 5, > + .num_counters = 4, > .num_boxes = 8, > .perf_ctr_bits = 48, > .fixed_ctr_bits = 48, So this changelog really sucks: what was the effect of the bug? Did we report bogus (or zero) counts for those non-existent counters - or did the code actually crash in a visible way? Thanks, Ingo