Am 07.03.2011 um 15:26 schrieb Esztermann, Ansgar: > On Mar 7, 2011, at 15:09 , Reuti wrote: > >> Am 07.03.2011 um 14:42 schrieb Esztermann, Ansgar: >> >>> Hi List, >>> >>> is anyone using the core binding feature on AMD Magny-Cours? If so, how do >>> you do it? For me, loadcheck mis-reads the topology as >>> (SCTTCTTCTTCTTCTTCTT)*4 rather than (SCCCCCCCCCCCC)*4. As far as I can >>> tell, there are two problems: >>> - the kernel (2.6.18-194.26.1.el5) only exposes core_id and >>> physical_package_id for each core, with core_id running from 0 to 5 and >>> physical_package_id from 1 to 4. However, there are two dice (nodes) per >>> socket, but this is not shown in the device tree. >> >> Confirmed. But I wonder, whether it's SGE's fault. Why does the kernel >> ouptut the same core id, although it's not the same core? > > Well, core IDs are unique only within the same socket ID (for older CPUs, say > Harpertown),
Yep. But it's working fine this way with former CPUs. > so I would assume the same holds for node IDs -- it's just that node IDs > aren't displayed for Magny-Cours. It's the physical ID which is changing for each socket. Magny-Cours just output doubles for "physical id" and "core id" entries. But the "apicid" and "initial apicid" are changing. But I don't know what's happening for Intel CPUs for these entries. Isn't it an issue of any kernel list? http://us.generation-nt.com/answer/patch-x86-wrong-proc-cpuinfo-core-id-amd-fam-f-model-9-help-199827011.html Looks like others found this too... -- Reuti > A. > > -- > Ansgar Esztermann > DV-Systemadministration > Max-Planck-Institut für biophysikalische Chemie, Abteilung 105 > > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
