(Forgot to CC the list)
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
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
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_at_dell-per810-01 utils]# ./hwloc-calc --objects core:0 2>/dev/null
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.
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.