Comments on: x86info glibc backwards compatibility.

By: davej

davej — Fri, 23 Jan 2009 01:07:27 +0000

heh, when we come to supporting >1k CPUs, we’ll probably have to rethink a number of things in x86info. I’m not sure the default output scrolling by would be too useful.
It’s already a little cumbersome at 16 CPUs as I recently found out. I think I’m going to work on this sometime soon to print a header like .. “Found 16 CPUs like this …”
rather than print the details out 16 times. Where it gets tricky is if there are differences between processors. (Which has already happened, and not just in weirdo asymmetric combinations of CPUs).

By: ntl

ntl — Fri, 23 Jan 2009 00:16:30 +0000

Yeah, I decided to not even try to support glibc 2.3 in my own project because of this. By the way, thought I’d point out that the way x86info uses the sched affinity APIs limits it to 1024 CPUs (the number of bits in a single cpu_set_t). You can discover the cpumask size used by the kernel at runtime and dynamically allocate your cpu_set_t’s but it’s a bit awkward — libtopology can help with that (topology_sizeof_cpumask). Likely this is not a pressing issue for x86info but maybe in a few years…