linux-kernel - Re: [PATCH 2/3] x86/topology: Fix AMD core count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.