(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
> [root_at_dell-per810-01 utils]# ./hwloc-calc --objects proc:1
> I have attached xml file if you want to check what's wrong. (I'm not using
> 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.