Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] comments on API changes
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2010-04-02 07:14:29

Fawzi Mohamed wrote:
> Building tools
> rather new autoconf/automake/libtool are requested
> I had to install them even on new clusters, nothing terrible, but I
> just noted it...

Yes, but there are nightly snapshots in
You don't need autotools there.

> pages info, before there were free pages, now I suppose that the
> page_types array might contain several pages, and so also the free
> pages, any place to get information about the meaning of the various
> page types? or is it still possible to get the free pages?

We only had the number of free pages for huge pages if I remember
correctly. Now we're supposed to have only the total number of pages,
huge or not, not the number of free ones. But Linux only reports the
number of free huge pages so that's what we actually show there.

The different page types are just (one page size + how many such pages
are available at boot). There's nothing specific about each page type
except its page size. So when you have hugepages, you have a page type
for 4kB pages, and another one for 2MB pages for instance. This was
designed to better cope with multiple page size since most modern
architectures support multiple huge page sizes. And some OS are already
able to use them. So in the end some machine may show 4 page type slots,
one for 4kB, one for 64kB, one for 2MB, one for 1GB, ...

> checkout, configure -> HWLOC_DEBUG 1 -> very chatty
> it could be that the debug is still considered the default for trunk,
> but 1.0 should definitely switch it off by default...

Debug is enabled by default when you build from a SVN checkout. I
actually never saw it since I always build outside of the source tree :)
Anyway, debug is not enabled by default in the tarballs (nightly
snapshots or actual releases) since there are no .svn directory there.

> C bitfields are used, normally they are avoided because they are slow
> (a compiler can bit or at compile time the constants and check/set
> several at once.
> Speed is not a concern here, but in any case I am wrapping to D that
> does not support bitfields directly, so I used flags, I was just
> wondering why bitfields were used...

Which bitfields are you concerned about?

Topology flags shouldn't be performance critical. Binding could be a bit
more performance critical, but I suspect that even a slow compiler will
generate code that's faster at parsing binding bitfields than the actual
binding system call.

> HWLOC_OBJ_SYSTEM seems on the way out
> I treated it just as a MACHINE anyway, but I wonder, as the constant
> is still there, does it have special attributes?, has it machine
> attributes? the documentation could be clearer...

This behavior changes completely in 1.0. SYSTEM will only be used when
assembling multiple independent machines, for instance with kerrighed,
or maybe for network topologies. MACHINE is always used now, and SYSTEM
should be very rare.

SYSTEM doesn't have any specific attribute, but it may have the
obj->name field set to != NULL so as to tell you what kind of
multiple-machine-assembly we're talking about.

We're slowly trying to move out of the type-specific attributes as much
as possible. In 1.1, we'll probably have an array of strings to contain
custom attributes such as machine name, model, system, ...

> I am looking forward to 1.0 ...

Me too, it's been way too long already :) We moved some features out of
1.0 back to 1.1 (memory binding for instance) because we wanted 1.0
early. We would probably have had time top implement them twice in the
meantime ;)

Could you point me at some precise documentation that is unclear or
missing so that I try to improve them before the 1.0 final release arrives?