From: Borislav Petkov <bp@alien8.de>
To: Prarit Bhargava <prarit@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: RFC: /proc/cpuinfo confusion with AMD processors
Date: Mon, 30 Jun 2014 15:13:09 +0200 [thread overview]
Message-ID: <20140630131309.GA5199@pd.tnic> (raw)
In-Reply-To: <53B15D27.9010306@redhat.com>
On Mon, Jun 30, 2014 at 08:50:47AM -0400, Prarit Bhargava wrote:
> AMD defines a "Package" as the hardware processor itself. Each Package contains
> multiple Nodes, and each Node has multiple Compute Units. Each Compute Unit can
> have up to 2 cores that [with the 62xx and 63xx] do not have multiple Threads.
>
> That is, to determine the number of CPUs that Linux sees, multiply
>
> Package * Nodes * Compute Units * Cores
>
> Note that Nodes and Compute Units are not indicated in /proc/cpuinfo directly
> (although it could be argued that they should be).
>
> The output of /proc/cpuinfo is confusing at this point as ...
>
>
> processor : 31
> vendor_id : AuthenticAMD
> cpu family : 21
> model : 2
> model name : AMD Opteron(tm) Processor 6386 SE
> stepping : 0
> microcode : 0x6000822
> cpu MHz : 2800.000
> cache size : 2048 KB
> physical id : 1
> siblings : 16 <<< this is number of threads per package
> core id : 7 <<< this is the core id of this thread relative to node
> cpu cores : 8 <<< this is the number of cores per node
siblings / cpu cores = threads per compute unit.
> which makes deciphering the system topology quite difficult as values are
> relative to both nodes and the entire package. It is not possible using this
> information to uniquely identify a processor.
To do what with that information? What is the task you're trying to
accomplish?
> Thoughts/concerns?
BIOS does all kinds of hacks and renumbering to accomodate the
brainf*cked design of other OSes so this info you're trying to put in
cpuinfo might turn to be completely misleading utterly useless in some
cases.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-06-30 13:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 12:50 RFC: /proc/cpuinfo confusion with AMD processors Prarit Bhargava
2014-06-30 13:13 ` Borislav Petkov [this message]
2014-06-30 13:29 ` Prarit Bhargava
2014-06-30 13:38 ` Borislav Petkov
2014-06-30 14:07 ` Prarit Bhargava
2014-06-30 18:27 ` Borislav Petkov
2014-07-02 22:01 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140630131309.GA5199@pd.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=prarit@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.