[libtopology-dev] sysfs cpu core_id attribute useless?

[Nathan Lynch]

Hi libtopology-dev!

Project home page: http://libtopology.ozlabs.org (nothing there yet
really)

Git repo: git://ozlabs.org/srv/projects/libtopology/libtopology.git

Big thanks to all those behind ozlabs.org for project and mailing list
hosting.  Hugh Blemings and Martin Schwenke got everything up and
running -- thanks guys!

For the list's inaugural message I'll describe an issue I'm having
with the topology information in sysfs.

Here's how libtopology builds a context:

for each cpu in sysfs (/sys/devices/system/cpu/cpu*)
	instantiate a "thread" object
	read "core_id" attribute
	if this core id has not been seen already
		instantiate a core object
	link thread to its core
	read "package_id" attribute
	if this package id has not been seen already
		instantiate a package object
	link up thread, core, and package

The problem I'm encountering is that value of core_id can be '0' when
the kernel doesn't actually know the core id -- '0' is the "fallback"
value the kernel provides in this case (for some reason, package_id's
fallback value is -1, which is easier to accommodate).  But '0' is a
perfectly valid core id, so it looks to the library like all logical
CPUs are on a single core...  with the NUMA support I added recently
the library blows up because it looks like we have the same core
present in multiple nodes.

I'm thinking about working around this by ignoring core_id and instead
using a hash of the contents of each logical CPU's thread_siblings
attribute to uniquely identify cores.  On systems where I've seen the
problem described above, thread_siblings is accurate.

Using a hash table will likely bloat the library's memory footprint a
bit so I'd appreciate any suggestions on alternative solutions.  Any
takers?