This bug really belongs to procinfo not Gentoo - but the listed maintainers website doesn't seem to exist, and we could fix it with a quickie patch in the ebuild file. procinfo detects the number of cpus by reading /proc/cpuinfo and (for x86 anyways) counting the number of times a line starts with "processor". The problem is that each CPU in my PIII also has a line in cpuinfo that says "processor id", so my 2 cpu system gets counted as 4 cpus, which then screws up the idle/sys/user time percentages. The one-liner fix is to change this: if (!strncmp ("processor",9)) /* Intel */ to this: if (!strncmp ("processor\t",10)) /* Intel */ at line 837 of procinfo.c
Hmm, apparently this practice is common. I noticed a similar problem (my dual cpu machine detected as 4 cpus) with "top", which comes from the procps package. I investigated the procps code, and found that it got the number of processors from a glibc library call. As it turns out, buried deep down in glibc is this exact same "bug" that procinfo has, which can be fixed the same way (adding a tab to the end of the "processor" search string). Perhaps if it's common between both procinfo and glibc to use a search for "processor" on /proc/cpuinfo to determine #cpus, the fix should be in the kernel? It could be trivially fixed there by changing the text for /proc/cpuinfo for PIII processor ids from "processor id" to something like "procid".
This is fixed on the kernel side in Alan's tree from 2.4.19-rc5-ac1 and onwards. It hasn't whoever been merged to the mainline tree. The comment from Alan's ChangeLog: o Switch 'processor id' to 'physical id' (me) | Keeps glibc happy until we sort out cpu numbers longer term gentoo-sources is still based on 2.4.19-pre7-ac2, but I assume gentoo-sources will catch up with this patch in due course on it's, so no need for this bug anymore, moving it to resolved.