Ok,
so physical OS index 0 and 1 are not true are physically near on the die.
Considering that, how I can use cache locality and cache sharing by cores if I don't know where my threads will physically bound?
If L#0 and L#1 where I bind my threads are physically far, may give me bad performance.
2011/8/4 Samuel Thibault
<samuel.thibault@inria.fr>
Gabriele Fatigati, le Thu 04 Aug 2011 16:14:35 +0200, a écrit :
> Socket:
> ______________
> | ____ ____ |
> | |core | |core | |
> | ____ ____ |
> | |core | |core | |
> | ____ ____ |
> | |core | |core | |
> | ______________|
>
> lstopo how create the numerations?
It does not really matter since there is no topology consideration here
(no shared cache or such). In that case hwloc will simply follow the
order as provided by the OS. If there were shared caches, they would
come into play when sorting the topology.
> It consider physical OS index to list and create cores topology? If
> yes, maybe Core L#0 and Core L#1 in a single socket are physically
> near.
Mmm, maybe the confusion comes from the expression "physically near".
What we call physical index have nothing to do with physical proximity.
It's just what the physical chip says, which often has nothing to do
with physical proximity.
There is nothing much fancy in the topology creation really: we simply
include objects one into the other according to logical inclusion, and
finally sort by OS (i.e. physical) index after it's all topology-sorted.
--
Ing. Gabriele Fatigati
HPC specialist
SuperComputing Applications and Innovation Department
Via Magnanelli 6/3, Casalecchio di Reno (BO) Italy
www.cineca.it Tel: +39 051 6171722
g.fatigati [AT]
cineca.it