(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@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@dell-per810-01 utils]# ./hwloc-calc --objects proc:0 > PU:0 > [root@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
