[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160321082340.GA15904@pd.tnic>
Date: Mon, 21 Mar 2016 09:23:41 +0100
From: Borislav Petkov <bp@...en8.de>
To: Huang Rui <ray.huang@....com>
Cc: Sherry Hurwitz <sherry.hurwitz@....com>,
Peter Zijlstra <peterz@...radead.org>, tglx@...utronix.de,
linux-kernel@...r.kernel.org, mingo@...nel.org, aherrmann@...e.com,
jencce.kernel@...il.com, Gang Long <gang.long@....com>
Subject: Re: [PATCH 2/3] x86/topology: Fix AMD core count
On Mon, Mar 21, 2016 at 11:07:46AM +0800, Huang Rui wrote:
> OK, we will find some fam15h, fam16h platforms to verify it. Please
> wait for my feedback.
>
> But I am confused with c->x86_max_cores /= smp_num_siblings, what is
> the real meaning of c->x86_max_cores here for AMD, the whole compute
> unit numbers per socket?
Yes, it is the cores and each core can contain two or more logical
threads. In AMD speak, that's the compute unit count. We read it in
detect_ht() from CPUID(1).EBX[23:16] which is LogicalProcessorCount,
i.e., CPUID(8000_0008).ECX[NC] + 1, i.e., the number of cores. And
"cores" in BKDG speak is the number of all cores in a processor which
are distributed across compute units....
That's why we divide by the number of siblings, i.e., the number of
cores in a CU, in AMD speak.
I know, it is confusing but once we're fine with the nomenclature, it'll
become as clear as day. :-)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists