[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160320184613.GF4230@pd.tnic>
Date: Sun, 20 Mar 2016 19:46:13 +0100
From: Borislav Petkov <bp@...en8.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>, aherrmann@...e.com,
jencce.kernel@...il.com, Rui Huang <ray.huang@....com>
Subject: Re: [PATCH 2/3] x86/topology: Fix AMD core count
On Sun, Mar 20, 2016 at 06:08:47PM +0100, Peter Zijlstra wrote:
> On Sun, Mar 20, 2016 at 02:09:26PM +0100, Borislav Petkov wrote:
> > First a question about the big picture: why is amd/core.c even
> > dealing with NB counters?
>
> It it not, it is dealing with Fam10 NB events.
>
> Fam10h doesn't have NB counters. Its NB events are on the same counters
> as all the other events. Its just that they have constraints.
See, and I was missing something: so there's the core x86_pmu and then
more PMUs get added with perf_pmu_register(). I.e., the uncore stuff, in
this case. Ok, makes sense...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists