Table of contents:
- What is the future of the PLPA?
- What is the API provided by the PLPA?
- Can I include the PLPA in my software project?
- How does the PLPA figure out which kernel API to use?
- I'm having a problem! What should I do?
|1. What is the future of the PLPA?|
The PLPA project is (or will be soon) deprecated by the Portable Hardware Locality (hwloc)
To be clear: all future development work is going into hwloc. See the
hwloc project announcements here
The first release of hwloc won't contain all of the PLPA
functionality; the ideas of PLPA are being slowly imported into hwloc
over time. For example, PLPA's embedding capabilities will definitely
not be in the first hwloc release -- but embedding is a feature in
hwloc's short-term roadmap (Editor's note: I wouldn't consider hwloc a
wholesale replacement for PLPA until embedding is available).
The PLPA API likely will not be directly carried over to hwloc; hwloc
already has its own API that will likely be extended over time to
include PLPA concepts. Hence, there will be a (small) porting effort
involved in converting PLPA-based applications to hwloc.
Please see the hwloc project
page and/or subscribe to the hwloc mailing lists for
|2. What is the API provided by the PLPA?|
The API provides a small number of C functions and
preprocessor macros. The API is best described through its header
|3. Can I include the PLPA in my software project?|
The PLPA was specifically designed to be safely included in other
software projects. The PLPA provides an M4 macro file suitable for
acinclude'ing in a top-level
configure script, and also has a
name-shifting mechanism for its API so that if multiple libraries
include name-shifted versions of the PLPA, there will be no symbol
The PLPA README file has more details on the name shifting
The PLPA is licensed under the BSD license.
|4. How does the PLPA figure out which kernel API to use?|
The PLPA uses the
syscall() interface to bypass GLibc and
directly call the get and set affinity functions in the Linux kernel.
This is because the GLibc API has changed multiple times, and there
are buggy versions in real linux distributions that cause problems.
Bypassing it and directly callign the kernel seemed the safest route.
But even so, the kernel has slightly changed its API a few times.
Mostly, this has to deal with the
len parameter (telling the kernel
how long the CPU set argument it). Careful examiniation of the kernel
source code has led to a fairly small number of safe tests that can be
performed to determine which size it expects.
The PLPA hides all this from the user -- it will figure out what size
the kernel expects and use it in all the
syscall() interactions with
the set and get affinity functions.
|5. I'm having a problem! What should I do?|
If you can't get the PLPA to compile, please see the Open MPI
Getting Help page to see what
details to send to the PLPA User's Mailing
If you are having problems with the PLPA run-time, please send a detailed message the PLPA User's Mailing
List describing what is going wrong. The more information that
you provide, the better. Mails saying "It doesn't work -- help me!"
will simply be met with requests for more information, so please just
sent it all the first time.
Please be sure to include the output of
plpa_info in your message.