[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56F0FDE7.8010802@amd.com>
Date: Tue, 22 Mar 2016 03:10:15 -0500
From: Sherry Hurwitz <sherry.hurwitz@....com>
To: Borislav Petkov <bp@...en8.de>, Huang Rui <ray.huang@....com>
CC: 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 03/21/2016 08:57 AM, Borislav Petkov wrote:
> +- AMD: the number of cores in a processor. On a system where cores are
> +clustered in groups of 2, 4 or more in compute units, this variable
> +denotes the number of*compute units* on the node.
> +
> +In both cases, the number of scheduling threads is computed by doing:
> +
> + x86_max_cores * smp_num_siblings
> +
> +This means:
> +
> +* smp_num_siblings: the number of siblings in a core. On AMD with
> +compute units, this number is the number of compute unit siblings,
> +i.e., compute unit cores in a single compute unit, according to their
> +nomenclature.
> -- hr
Boris, this documentation will help tremendously. In just this line of
code:
nr_local_cpus = nr_cores * nr_siblings
we have an Intel HT = AMD core = logical_cpu
and core = AMD compute unit.
Anybody surprised there was a bug?
The surprising thing is that running lscpu on a 32 core 2 socket 6300
Opteron system without
the patches I get the same output as with the patches and it matches
Ray's. I don't see an impact.
Powered by blists - more mailing lists