Greetings PLPA fans!
This list has been dormant for quite a while. I wanted to a) update
you on what has been happening with PLPA and b) ask for some testing
help. This is all motivated by the fact that until this point PLPA
has been a side-project for me -- nights and weekends kind of stuff.
But recently, it has become important for PLPA to be properly and
fully integrated into Open MPI, so now I can spend some workday time
on PLPA.
Here's what's been happening over the past few months:
1. AMD contributed some code that turned into the basis for PLPA now
understanding sockets and cores (for recent enough Linux kernels --
must be >= 2.6.16). Specifically, PLPA grew the following API
functions:
int plpa_have_topology_information(void);
Returns true if the kernel supports (socket,core) tuple information
(and whether several of the other new PLPA functions will work).
int plpa_map_to_processor_id(int socket, int core, int *processor_id);
Map (socket,core) tuple to virtual processor ID
int plpa_map_to_socket_core(int processor_id, int *socket, int *core);
Map processor_id to (socket,core) tuple
int plpa_max_processor_id(void);
Return the max processor ID
int plpa_max_socket(void);
Return the max socket number
int plpa_max_core(int socket);
Return the max core number for a given socket
void plpa_finalize(void);
Shut down PLPA (release some memory). There's no explicit
"plpa_init" function required; PLPA will cache some internal
data (processor ID <--> (socket,core) tuple mappings) when
necessary. plpa_finalize() simply releases all of this memory.
The README file was updated to have some information on these functions.
The idea is that if you want to schedule on a specific (socket,core)
tuple, you can use the new functions to calculate its Linux virtual
processor ID and then use the normal PLPA setaffinity function to
bind a process there.
2. PLPA grew a new command line executable: plpa-taskset. The intent
is to support all the same syntax as the existing taskset(1) command,
but also to support (socket,core) tuple syntax. Hence, you can use
plpa-taskset to launch executables on arbitrary CPU set masks and/or
specific (socket,core) sets (Paul Hargrove was extremely helpful as a
sounding board while I was figuring out what the syntax should be).
- The general notation is "core_at_socket", such as "1_at_2" (core 1 on
socket 2)
- Examples:
- binding to core 3 on socket 1 is "3_at_1"
- binding to core 1 on all sockets is "1_at_all"
- binding to all cores on socket 2 is "all_at_2"
- binding to all cores on sockets 2 and 3 is "all_at_2,all_at_3" OR
"all@{2,3}"
- binding to cores 1 and 2 on sockets 0, 1, and 3 is
"{1,2}@{0,1,3}"
- binding to cores 0, 1, and 2 on sockets 0, 1, 2, and 5 is
"{0-2}@{0-2,5}"
- binding to all cores on all sockets (effectively disables PA)
"all_at_all"
More details here: https://svn.open-mpi.org/trac/plpa/browser/trunk/
src/plpa-taskset/info.txt.
Additionally, the string "parent" can be used for PID's (allowing you
to fork/exec plpa-taskset and affect the affinity of the parent
process).
3. plpa_info was renamed to be plpa-info (because I'm lazy -- why hit
the "shift" key?). Since PLPA doesn't have huge/widespread adoption
yet, I figured it was safe to do this renaming. plpa-info also now
displays (socket,core) topology information if the system that it is
running on supports it.
4. Some improvements were made in the "included" mode to allow better
integration of PLPA into larger software projects.
The plan is to release this new stuff as PLPA v1.1. I don't think
it's fully ready yet, here's what I think still needs to happen:
- I don't think that the parsing of the (socket,core) syntax in plpa-
taskset is 100% right yet, but it's close.
- Should really have man pages for the PLPA API functions
- Need a plpa-info man page
- Need a plpa-taskset man page
I've put a "1.1a1" SVN snapshot tarball on the following web page:
http://www.open-mpi.org/software/plpa/download.php
But I expect it to get stale; your best bet would be to get an SVN
checkout of PLPA from the following URL:
http://svn.open-mpi.org/svn/plpa/trunk
I could really use some help with comments/opinions and/or testing of
all the new stuff.
Thanks!
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}