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]
Message-ID: <20140630131309.GA5199@pd.tnic>
Date:	Mon, 30 Jun 2014 15:13:09 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: RFC: /proc/cpuinfo confusion with AMD processors

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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ