When trying to discover the NUMA topology of a system in a script, for example. lscpu -p seems the perfect format to do so. However, it's not accurate, because the CPU identifiers given in the first column bear no relation whatsoever to the actual CPU's as seen by the OS. Take this from an IBM x440 (I think) running RHEL5.4 (which is a 2x4-core Nehalem): [jstanley@xen06 ~]$ ./lscpu -p # The following is the parsable format, which can be fed to other # programs. Each different item in every column has an unique ID # starting from zero. # CPU,Core,Socket,Node,,L1d,L1i,L2,L3 0,0,0,0,,0,0,0,0 1,1,0,0,,1,1,1,0 2,2,0,0,,2,2,2,0 3,3,0,0,,3,3,3,0 4,4,1,1,,4,4,4,1 5,5,1,1,,5,5,5,1 6,6,1,1,,6,6,6,1 7,7,1,1,,7,7,7,1 CPU's 0-3 might not be on node0 (though in this particular system, they happen to be - I was trying to find a non-work system exhibiting the problem and failed :) ). At any rate, on an Opteron at work, the output looks very similar, but node 0 consists of CPU's 0 and 2, not 0 and 1. It gets worse when you get into higher-core systems. I looked into the source code, and it appears that lscpu actually throws away all of the NUMA topology information that it gets. If I read the source code correctly, then it counts the number of nodes, cores, and sockets by looking only at cpu0, and simply says "OK, there's 4 cores/socket here, let's call them 0-3 and 4-7, regardless of what the OS thinks they are". Not entirely useful. My C-fu is much too weak to attempt to patch this, but I can provide testing if needed :).. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
