Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] Ad
From: Jirka Hladky (jhladky_at_[hidden])
Date: 2010-07-07 12:23:02


(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_at_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