(Forgot to CC the list) Hi Brice,
On Wednesday, July 07, 2010 04:16:19 pm Brice Goglin wrote: > 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. Right. I completely agree. > > > BTW, --objects reports Cache (It would be useful to add the size of Cache > > to the report) > > Could add that to -v maybe. That was my point. STDOUT output has to stay intact. This is nice-to-have (IMHO very low priority) for STDERR. > 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); I do agree with you. hwloc_get_largest_objs_inside_cpuset does it right. On the other hand, I do believe that on user level you would expect --objects to give you the parrent object. If it gives you the same object as in input it's not useful. IMHO, hwloc_get_largest_objs_inside_cpuset is right but hwloc-calc --objects should call hwloc_get_largest_objs_inside_cpuset 2 times on system with hyperthreading enabled to get meaningful output. You can perhaps solve this problem by adding the new option --ancestor_tree to show all ancestors. IMHO, these options do not belong to hwloc-calc utility anyhow. The output of this utility should be passed to either numactl or taskset or hwloc-bind. The output of objects option does not fit into this framework: [root@dell-per810-01 utils]# ./hwloc-calc --objects core:0 2>/dev/null L2Cache:0 IMHO, not even hwloc-bind can handle "L2Cache:0" output. I would suggest to move --objects option to hwloc-info or change it's behaviour so that it gives output useful for CPU affinity commands (taskset, numactl, hwloc-bind) Please notice that I'm not using --objects option in real life and I may be just wrong. These are just mine 2 cents. > > >> 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. Thanks Brice!! I do apologize for the long posts today. I really love hwloc. Perhaps I'm just too picky:-) and I'm pointing out tiny problems. You see, I'm not using -- objects but I will definitely use --list option once it's released. Greetings, Jirka
