>> _______________________________________________________________ >> | | | | | | | | | >> | cpu0 | | | | | | | | >> |______| core0 | | L1d | L1i | L2d | | | >> | | | | 16K | 16K | 256K | | | >> | cpu1 | | | | | | | | >> |______|_______| processor0 |_____|_____|______| L2i | L3 | >> | | | | | | | 1024K | 12288K | >> | cpu2 | | | | | | | | >> |______| core1 | | L1d | L1i | L2d | | | >> | | | | 16K | 16K | 256K | | | >> | cpu3 | | | | | | | | >> |______|_______|____________|_____|_____|______|_______|________| >> | | | | | | | | | >> | cpu4 | | | | | | | | >> |______| core2 | | L1d | L1i | L2d | | | >> | | | | 16K | 16K | 256K | | | >> | cpu5 | | | | | | | | >> |______|_______| processor1 |_____|_____|______| L2i | L3 | >> | | | | | | | 1024K | 12288K | >> | cpu6 | | | | | | | | >> |______| core3 | | L1d | L1i | L2d | | | >> | | | | 16K | 16K | 256K | | | >> | cpu7 | | | | | | | | >> |______|_______|____________|_____|_____|______|_______|________| L2d/L2i separated doesn't make sense? Also if you consider special cases like the P4 trace caches it might be difficult to fit them in. If you add a node level it would get fairly complicated? Especially since the topology might be large and complicated (ever looked at an Altix interconnect graph?). 80 characters would be likely not enough. On the other hand numa information could be kept in numactl --hardware which already does a reasonable job (of course I'm biased) The advantage of the eye candy version would be that hopefully people wouldn't get the idea of parsing it in programs. The 12288K should be "12M" I'm a little concerned that the topology information is not accurate enough and might end up misleading. Being more vague might be better. -Andi -- 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
