codemonkey.org.uk » x86info

10 years of x86info.

davej — Sat, 26 Feb 2011 18:06:03 +0000

On Mon Feb 26 2001, I committed the first version of x86info to CVS on sourceforge. The actual coding of that first version had happened during the week or so prior.

The project began after seeing the program ‘cpuid’ by Phil Karn. I had sent a few patches to Phil but never got any reply, and no new release of cpuid appeared until months later (not including my patches). As I ended up forking more and more of the code, I decided to push it out as ‘x86info’ for the first time. Phil did a few more releases, up until 2002, when the program was abandoned.

Over the years, x86info has seen 739 commits from at least 19 contributors (some patches written by others were committed in the CVS days without correct attribution). The bulk of the commits were unsurprisingly mine.

The commit rate year by year is interesting.

2001 197
2002 119
2003 88
2004 17
2005 37
2006 46
2007 34
2008 74
2009 65
2010 27
2011 54

2003 was when I got hired at Red Hat, and the Fedora kernel pretty much became my life. 2004 I was doing RHEL4 too. The drop-off around that time is significant, and doesn’t recover until several years later.
This year seems to be off to a good start

x86info has been ported to Solaris and FreeBSD, and at one time, even to Microsoft Windows. That support was ultimately removed due to the number of invasive ifdefs present. The various ports sometimes get broken due to lack of testing during development time, but afaik they are available in ‘ports’ with whatever fixes need to be present.

Asides from the Linux kernel, this is the oldest project I’m involved in that is still seeing development.

10 years of x86info. is a post from: codemonkey.org.uk

No related posts.

x86info processor topology parsing.

davej — Sat, 12 Dec 2009 03:01:14 +0000

Today was my last working day of the year, as I’ve accumulated some ridiculous amount of time off that needs to be taken.
Before I disappeared for three weeks, I wanted to get something finished that I’ve been working on for a while. I got close too.
The development tree of x86info (ie, git or snapshots) now has a nifty new feature where after parsing all the processors it finds, it determines how they’re connected, and prints out what it thinks the topology looks like.

So where 1.25 used to print out garbage like..
APIC ID: 0x1 Package: 0 Core: 0 SMT ID 1

The new code prints out something much more readable.
Summary: This system has 1 dual-core processor with hyperthreading (2 threads per core) running at an estimated 2.95GHz Total processor threads: 4

I’ve thrown it at several different kinds of processor topologies (single/dual/quad core), with and without hyperthreading, and it seems to do the right thing in all cases. Currently this code is Intel only. It may do the right thing on other vendors in some situations, but there are definitly cases where it doesn’t.

I’ll tackle the other vendors in the new year. If you find any Intel systems where it doesn’t print out the right thing, drop me an email with x86info -a –debug. (Don’t email me non-Intel ones, unless it does something really nasty like segfault).

Though as I’m on vacation, it’ll probably be the new year before I fix it up, unless I get bored.
When the new year comes and I’ve added the other vendor support, I’ll roll out a 1.26 release with this and whatever else I have queued up.

Happy holidays.

x86info processor topology parsing. is a post from: codemonkey.org.uk

No related posts.

x86info 1.24

davej — Fri, 06 Feb 2009 17:24:36 +0000

I just pushed out a new release of x86info.
Not a huge amount of stuff changed, but it has recognition for Atom, and Nehalem, which are becoming widespread enough that it’s worth doing a release. I also added a few older quad core CPUs that I previously overlooked last time I went through the spec update datasheets.

The results/ directory is looking a little neglected. If anyone wants to send me examples for CPUs not presently in there, I’ll get them added. A zillion ‘core 2′ entries isn’t really so interesting, so unless there’s a compelling difference between models, I’ll only add one from each generation.

Oh, and this release requires a minimum of glibc 2.4 (so did earlier ones for the last few releases, but now there’s an explicit check)

x86info 1.24 is a post from: codemonkey.org.uk

No related posts.

x86info glibc backwards compatibility.

davej — Wed, 21 Jan 2009 17:28:19 +0000

Sometimes, backwards compatibility gets really ugly.
Today I got a mail from someone who failed to compile x86info on some old system, because it had an old glibc.
x86info uses the affinity system calls to bind processes to specific CPUs. I had forgotten all about it, but earlier versions of the interface in glibc were a little unstable.
Quoting the sched_getaffinity manpage:

VERSIONS
The CPU affinity system calls were introduced in Linux kernel 2.5.8. The library interfaces were introduced in glibc 2.3. Initially, the glibc interfaces included a cpusetsize argument, typed as unsigned int. In glibc 2.3.3, the cpusetsize argument was removed, but was then restored in glibc 2.3.4, with type size_t.

The email I got was kind enough to include a patch that made it work on all possible combinations of the glibc, by using plpa. It’s neat that this rube goldberg machine can make it work with anything, but damn is it ever ugly.

I settled for a simpler “fix”

It’s a controversial answer, but sometimes, compatibility just isn’t worth it.

x86info glibc backwards compatibility. is a post from: codemonkey.org.uk

No related posts.

x86info hacking.

davej — Thu, 15 Jan 2009 05:46:50 +0000

Spent much of the afternoon today working on some updates for x86info. The CPU database within it needs to be constantly updated whenever Intel (or any other vendor) release new processors. This means sifting through dozens of datasheets, and trying to come up with the logic to distinguish between them. Once upon a time, it was a simple case of matching the cpuid family/model/stepping pair. Then circa Pentium 3/Celeron era, things got more complicated, and you had to take the L2 cache size into consideration too. As time went on, more and more things needed to be checked before you could make a decision. The maximum MHz the CPU runs at for example. Or the number of cores on a die. It’s all getting really, really complicated.

It’s further complicated by the fact that in some cases, Intel have re-used part numbers.

x86info is a mess of nested if’s and switches as a result of the above. I toyed with the idea of making it somehow database driven a few years ago, but of course, it’s one of those projects that never seems to happen. Maybe one day I’ll get around to it.

Today I added recognition of Nehalem, Atom and a bunch of older Core2′s that I had missed in the last update.
I’m hoping to get an update out sometime in the next week or two. I still need to pore over a bunch of those datasheets, double-checking what else I’ve missed.

x86info hacking. is a post from: codemonkey.org.uk

No related posts.