linux-kernel - Re: [PATCH] x86: Consider multiple nodes in a single socket to be "sane"

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 17 Sep 2014 14:55:26 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Dave Hansen <dave@...1.net>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, mingo@...nel.org,
	hpa@...ux.intel.com, ak@...ux.intel.com,
	Alex Chiang <achiang@...com>, Borislav Petkov <bp@...e.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Mike Travis <travis@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [PATCH] x86: Consider multiple nodes in a single socket to be
 "sane"

On Tue, Sep 16, 2014 at 01:17:44AM -0700, Dave Hansen wrote:
> >> This also fixes sysfs because CPUs with the same 'physical_package_id'
> >> in /sys/devices/system/cpu/cpu*/topology/ are not listed together
> >> in the same 'core_siblings_list'.  This violates a statement from
> >> Documentation/ABI/testing/sysfs-devices-system-cpu:
> >>
> >> 	core_siblings: internal kernel map of cpu#'s hardware threads
> >> 	within the same physical_package_id.
> >>
> >> 	core_siblings_list: human-readable list of the logical CPU
> >> 	numbers within the same physical_package_id as cpu#.
> > 
> > No that statement is wrong; it assumes physical_package_id is a good
> > identifier for nodes. Clearly this is no longer true.
> 
> I went back and re-read the text around there.  I don't see any mention
> of nodes or NUMA.  It's just talking about the topology within the CPU
> from what I can tell.
> 
> Good thing it's just in "Documentation/ABI/testing/" I guess.
> 
> Either way, are you saying that a core's "physical_package_id" should
> depend on what BIOS options get set, and that different cores in the
> same physical package should have different "physical_package_id"s?

This sounds misleading to me. If I would have to explain how I
understand physical_package_id, I'd say it is the physical piece of
silicon containing the core. Which is consistent with what Peter says
that using it to identify NUMA nodes is wrong.

Btw, I'm trying to get on an AMD MCM box to dump those fields but it is
kinda hard currently. Will report back once I have something...

-- 
Regards/Gruss,
    Boris.
--
--
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/