Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: [hwloc-devel] Fwd: Ad
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2010-07-07 10:21:14


(Forgot to CC the list)

Le 07/07/2010 13:40, Jirka Hladky a écrit :
> Well, I would expect to get following reported on STDERR (refer to lstopo
> output) when -v is specified:
>
> ./hwloc-calc -v --list 4 proc:60
> L2 #30 (256KB)
>
> ./hwloc-calc -v --list 5 proc:60
> L1 #30 (32KB)
>
> ./hwloc-calc -v --list 6 proc:60
> Core #30
>
> Without "-v" it's fine to report just a number. Does it make sense?
>

Well, --list was designed to generate x,y,z strings that may be passed
to external tools such as numactl or taskset. Adding the type as a
prefix would not help much there.

> BTW, --objects reports Cache (It would be useful to add the size of Cache to
> the report)
>

Could add that to -v maybe.

> I do believe that --objects is fooled by hyper threading being enabled when
> trying to traverse to the next (parent) object in hierarchy.
>
> I have tested it on another box:
> ===========================================
> CPU GenuineIntel Intel(R) Xeon(R) CPU E6510 @ 1.73GHz
> Processors 16
> Cores 8
> Sockets 2
> Hyperthreading True
>
> [root_at_dell-per810-01 utils]# ./lstopo
> Machine (4025MB)
> NUMANode #0 (phys=0 2005MB) + Socket #0 + L3 #0 (12MB)
> L2 #0 (256KB) + L1 #0 (32KB) + Core #0
> PU #0 (phys=0)
> PU #1 (phys=8)
> L2 #1 (256KB) + L1 #1 (32KB) + Core #1
> PU #2 (phys=2)
> PU #3 (phys=10)
> L2 #2 (256KB) + L1 #2 (32KB) + Core #2
> PU #4 (phys=4)
> PU #5 (phys=12)
> L2 #3 (256KB) + L1 #3 (32KB) + Core #3
> PU #6 (phys=6)
> PU #7 (phys=14)
> NUMANode #1 (phys=1 2020MB) + Socket #1 + L3 #1 (12MB)
> L2 #4 (256KB) + L1 #4 (32KB) + Core #4
> PU #8 (phys=1)
> PU #9 (phys=9)
> L2 #5 (256KB) + L1 #5 (32KB) + Core #5
> PU #10 (phys=3)
> PU #11 (phys=11)
> L2 #6 (256KB) + L1 #6 (32KB) + Core #6
> PU #12 (phys=5)
> PU #13 (phys=13)
> L2 #7 (256KB) + L1 #7 (32KB) + Core #7
> PU #14 (phys=7)
> PU #15 (phys=15)
>
> [root_at_dell-per810-01 utils]# ./hwloc-calc --objects proc:0
> PU:0
> [root_at_dell-per810-01 utils]# ./hwloc-calc --objects proc:1
> PU:1
> ===============================================
>
> I have attached xml file if you want to check what's wrong. (I'm not using
> --objects
> at the moment. I just wanted to see what it does.)
>
> --objects works fine no boxes without hyper threading. However, it seems to do
> the wrong thing on boxes with hyper threading.
>

the above is expected. --objects return the largest objects included
inside your input.

The largest object inside a hypethread is this hyperthread. The largest
object inside two hyperthreads of the same core is this entire core. The
largest objects inside 2 hyperthreads of one core and another
hyperthread of another core is the first core + the other hyperthread.
See ? Maybe it's not well documented, and --objects is probably not the
right name. In the API, I say:

/** \brief Get the first largest object included in the given cpuset \p set.
 *
 * \return the first object that is included in \p set and whose parent is not.
 *
 * This is convenient for iterating over all largest objects within a CPU set
 * by doing a loop getting the first largest object and clearing its CPU set
 * from the remaining CPU set.
 */
hwloc_obj_t hwloc_get_first_largest_obj_inside_cpuset(hwloc_topology_t topology, hwloc_const_cpuset_t set);

/** \brief Get the set of largest objects covering exactly a given cpuset \p set
 *
 * \return the number of objects returned in \p objs.
 */
int hwloc_get_largest_objs_inside_cpuset (hwloc_topology_t topology, hwloc_const_cpuset_t set, hwloc_obj_t * __hwloc_restrict objs, int max);

>> Yes, recently added error messages are ok, I need to fix the old ones,
>> those that only appear in verbose mode.
>>
> Thanks! :-)
>

I committed this fix.

Brice