Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] towards PLPA-like API in 1.0
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2009-11-12 13:41:23


Jeff Squyres wrote:
>> Well, the list of good ideas will be very short then :) Most remaining
>> functions are about manipulating core and socket ids, we don't need that
>> at all in hwloc anymore.
>
> FWIW, having a "simple" API like that might be a Good Thing...?
>
> I.e., just be able to bind to a specific thread/core/socket with a
> minimum fuss/muss. Even if such an API would be mainly syntactic sugar
> for other hwloc functionality -- there definitely is something to be
> said for "make the simple things simple". It will definitely (IMNSHO)
> extend hwloc's reach into a larger class of applications. Meaning:
> there are a variety of hard-coded apps out there that we'll never see;
> apps that run on specific servers for specific purposes, where the
> developers hard code in there "bind to cores 1-4" or "bind to sockets
> 1,3" because they already know the setup and this app is not intended
> to be portable.

Oh sorry, I wasn't clear. I am not against a socket+core API [1]. What I
find useless with hwloc is using the physical/OS ids. hwloc/plpa.h uses
obj->os_index everywhere, while os_index is meaningless excep at the
PROC level (when binding). If you want the second core in the second
socket, you don't care about their physical/OS indexes (which are often
non-consecutive, repeating, ...), you just want to use logical indexes.
OS/physical indexes change all the time anyway (when upgrading the BIOS,
the kernel, ...).

> It may be useful to have the API be extensible;

I don't see how you could be extensible without being close the generic
hwloc API.

> one thing I have heard rumors about coming in the not-distant future
> is the concept of "boards" (multiple motherboards in a single box).
> I.e., socket IDs may be repeated; they are differentiated by board
> number.

Actually, we've seen many strange things like this in the non-x86 world.
It doesn't look very different from Bull's QBBs or SGI Blades in large
Itanium machines :)

Brice

[1] But we'll have to choose between socket+core and NUMA+core (often
similar but not always), and maybe other useful basic setups.