Thanks both for the fast response! I upgraded to 3.2 kernel from the unstable and now I get the right ones: http://dl.dropbox.com/u/258337/lstop_odysseus_1.4.1_kernel3.2.pdf
This is a longstanding kernel bug. It was finally fixed recently in kernel 3.3 and backported in 3.2.9 and 3.0.23. Not sure if the Debian kernel devs would accept backporting it to squeeze. The relevant commit is.
commit 32c3233885eb10ac9cb9410f2f8cd64b8df2b2a1 Author: Andreas Herrmann <email@example.com> Date: Wed Feb 8 20:52:29 2012 +0100 x86/amd: Fix L1i and L2 cache sharing information for AMD family 15h processors For L1 instruction cache and L2 cache the shared CPU information is wrong. On current AMD family 15h CPUs those caches are shared between both cores of a compute unit. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=42607
If you need to stay with an old kernel that can't be fixed for this machine, we can provide you with a corrected XML topology.
On 19/04/2012 13:51, Petros Aristidou wrote:Hi everyone,
I run lstopo on my 4-socket 6238, Supermicro system and I get the following figures: http://dl.dropbox.com/u/258337/lstop_odysseus_1.4.1.pdf and
It shows that each socket has 2 numanodes with 6 cores each. It shows a shared L3 memory but dedicated L2 and L1. In other references, like:I get that L1 is dedicated, L2 is shared by 2 cores and L3 shared by all 6 in the numanode.
What's the truth? Is lstopo wrongly reporting that?
I am running the latest stable version of Debian Linux (6.0.4 Squeeze) with all updates and have hwloc v1.4.1 installed.
Any insight is welcome!
_______________________________________________ hwloc-users mailing list firstname.lastname@example.org http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users
hwloc-users mailing list