[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <524DE349.4050000@gmail.com>
Date: Thu, 03 Oct 2013 23:36:09 +0200
From: Brice Goglin <brice.goglin@...il.com>
To: Stephan von Krawczynski <skraw@...net.com>
CC: linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: NUMA processor numbering
Le 03/10/2013 12:46, Stephan von Krawczynski a écrit :
> Ok, let me re-phrase the question a bit.
> Is it really possible what you see here:
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 45
> model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
> stepping : 7
> microcode : 0x70d
> cpu MHz : 2002.000
> cache size : 20480 KB
> physical id : 0
> siblings : 16
> core id : 0
> cpu cores : 8
> apicid : 0
> initial apicid : 0
> [...]
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 45
> model name : Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
> stepping : 7
> microcode : 0x70d
> cpu MHz : 1518.000
> cache size : 20480 KB
> physical id : 1
> siblings : 16
> core id : 0
> cpu cores : 8
> apicid : 32
> initial apicid : 32
> [...]
>
> These are the first two in the cpu list. If you look at that they are both on
> core id 0, but have different physical ids. Up to now I thought that processor
> 1 is the HT of core id 0. But with a different physical id this would mean
> that they are different NUMA nodes, right? How can that be? Someone from Intel
> with a hint?
Such "unexpected" numberings are very common. The BIOS is free to number
processors in many different orders, including NUMA first, core first,
HT first, etc.
Having the two hyperthreads of the first core physically numbered 0 and
1 doesn't seem very common on current Intel platforms. Most Xeon E5
machines I've seen put the second hyperthreads of all cores at the end
of range. But there's no guarantee about this.
Use hwloc just like Henrique said, it will take care of virtually
reordering objects in a logical manner.
Brice
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists