1
1
Граф коммитов

21 Коммитов

Автор SHA1 Сообщение Дата
Jeff Squyres
900631e9f9 - Add a first cut of the memory affinity (maffinity) framework. It's
API is still a bit unstable and may change.
- Add a primitive "first use" component that simply has each process
  "touch" the pages that they want to use, thereby [hopefully] locking
  them locally to a specific processor
- Add hooks in ompi_mpi_init to enable memory affinity when processor
  affinity is used.
- Added hooks in ompi_mpi_finalize to shut down memory affinity when
  it was initialized during ompi_mpi_init.
- Added right hooks in ompi_info to display maffinity components.

This commit was SVN r7044.
2005-08-26 10:56:39 +00:00
Jeff Squyres
626389254e Fix typo
This commit was SVN r7040.
2005-08-25 20:24:22 +00:00
Brian Barrett
dfdb5dc12a * high resolution, low latency timers for a number of platforms, plus mods
to opal_progress() to use the timers instead of a tick count for deciding
  whether to call the event loop or not.  Currently supported platforms are:

     - solaris (x86 / sparc)
     - Linux (x86 / x86_64 / IA64)
     - Mac OS X (x86 / Power PC)

This commit was SVN r6922.
2005-08-18 05:34:22 +00:00
Jeff Squyres
a7058bbe43 Be friendly -- if paffinity is requested and we are unable to set it
(for any reason), print a friendly warning message.

This commit was SVN r6907.
2005-08-16 17:18:56 +00:00
Jeff Squyres
409b9e73b2 Remove debugging printf. Doh!
This commit was SVN r6905.
2005-08-16 16:20:55 +00:00
Jeff Squyres
f5cc86fa07 - Add MCA param mpi_paffinity_alone, which, when nonzero, will assume
that this ORTE job is the only one on the nodes involved, and if
  told what processors to assign the processes to, will bind MPI
  processes to specific processors.
- Convert #include's to new style
- Convert some <tab>'s to spaces

This commit was SVN r6904.
2005-08-16 16:17:52 +00:00
Jeff Squyres
c465eb8567 Rename opal/threads/thread.h -> opal/threads/threads.h to avoid a
naming conflict with Solaris' <thread.h>

This commit was SVN r6879.
2005-08-15 11:02:01 +00:00
Jeff Squyres
cf16a521c8 Ensure to get ompi/include/constants.h
This commit was SVN r6845.
2005-08-12 21:42:07 +00:00
George Bosilca
8b93cb7661 Rename all the functions starting with mca_base_modex to mca_pml_base_modex.
Change all the places where they are used to fit the new name.

Remove the code to check the remote arch from the PML. We will have a GPR mechanism
in ompi_mpi_initialize to do that.

This commit was SVN r6750.
2005-08-05 18:03:30 +00:00
Jeff Squyres
4c1dd716c7 Change and add new features to the MCA parameter system:
- new preferred API calls for registering MCA parameters are
  mca_base_param_reg_{int|string} and
  mca_base_param_reg_{int|string}_name.
- See opal/mca/base/mca_base_param.h for docs on new calls.  
- Can now register and lookup a value at the same time.
- Can now mark a parameter "read only" at registration time
- Can now mark a parameter "internal" at registration time
- Can now associate a help message with the parameter at registration
  time; displayed in the ompi_info output.

The old API calls are still available for backwards compatibility
(mca_base_param_register_{int|string}.  They will eventually be
removed -- all developers are encouraged to use the new APIs from here
on out and replace any old calls with the new API.

Some params were also renamed -- the previous convention of using
"base_" as a prefix for any param that was not associated with a
component is henceforth deprecated.  Instead, use one of the following
prefixes:

mca: for anything in the MCA base itself
opal: for anything in OPAL
orte: for anything in ORTE
mpi: for anything in OMPI

This commit was SVN r6698.
2005-08-01 22:38:17 +00:00
Ralph Castain
4e79a51395 Add a job_info segment to the system that holds a container for each job. Within each container is a keyval indicating the job state (i.e., all procs at stage1, finalized, etc.). This provides a rough state-of-health for the job.
This required a little fiddling with a number of areas. Biggest problem was that it uncovered a potential for an infinite loop to be created in the registry. If a callback function modified the registry, the registry checked the triggers to see if anything had fired. Well, if the original callback was due to a trigger firing, that condition hadn't changed - so the trigger fired again....which caused the callback to be called, which modified the registry, which checked the triggers, etc. etc.

Triggers are now checked and then "flagged" as being "in process" so that the registry will NOT recheck that trigger until all callbacks have been processed. Tried doing this with subscriptions as well, but that caused a problem - when we release processes from a stagegate, they (at the moment) immediately place data on the registry that should cause a subscription to fire. Unfortunately, the system will just hang if that subscription doesn't get processed. So, I have left the subscription system alone - any callback function that modifies the registry in a fashion that will fire a subscription will indeed fire that subscription. We'll have to see if this causes problems - it shouldn't, but a careless user could lock things up if the callback generates a callback to itself.

Also fixed the code that placed a process' RML contact info on the registry to eliminate the leading '/' from the string.

This commit was SVN r6684.
2005-07-29 14:11:19 +00:00
George Bosilca
8e0d8a0e99 The datatype should be initialized as soon as possible. Inside we detect the local architecture and
create the local convertor. They will get used on the ompi_proc_init.

This commit was SVN r6680.
2005-07-29 00:15:26 +00:00
George Bosilca
3b52a31e1f Make some compilers quiet. Otherwise they complain about uninitialized variables even if
the logic inside prevent an execution path where they can be used uninitialized.

This commit was SVN r6560.
2005-07-20 06:47:10 +00:00
George Bosilca
6aa956241f Solve the issues when several PML are available. The main problem here come from the fact that an PML
is a lot more difficult than a PTL, and it can adapt it's behavior to the level of threading required
by the user. In this case the behavior is the priorit of the PML. Therefore this information is never
availale before the init function (of the PML) is called. So I try to keep nearly the same structure
as it was before, with one change. When a PML get initialized it does not necessarily means it has been
selected, so it does not means it has to create all it's internal structures (and select the PTL and
all this stuff). They can all be done later, when a PML knows that it definitively get selected
(when the enable function is called with the argument set to true). Thus, in the case of a PML close
one have to check if the PML has been selected or not before trying to clean up the internals.

I had to change the MPI_Init function to allow the PML to be enabled before we start adding procs inside.

This commit was SVN r6434.
2005-07-12 05:40:56 +00:00
Josh Hursey
de5e0d4f2c (Re-)Added two MCA Parameters that must have been lost in the merge way back when:
* mpi_show_mca_params
   If set to true, this turns on the dumping of all MCA parameters when MPI_INIT is called. 
   Only the 'rank 0' processes will print the parameters.

* mpi_show_mca_params_file
   (This value is only used if the first argument is set to true) If this value is non-NULL 
   it specifies the file to put the dump into. This file can then be used as input to mpirun 
   for debugging purposes. If this value is not set (and mpi_show_mca_params is set) then 
   the parameters are dumped to stdout.

This commit was SVN r6401.
2005-07-08 21:01:37 +00:00
Brian Barrett
170ef8af1f * rename ompi_show_help to opal_show_help
* rename ompi_stacktrace to opal_stacktrace
* rename ompi_strncpy to opal_strncpy

This commit was SVN r6336.
2005-07-04 02:38:44 +00:00
Brian Barrett
a13166b500 * rename ompi_output to opal_output
This commit was SVN r6329.
2005-07-03 23:31:27 +00:00
Brian Barrett
23b687b0f4 * rename ompi_event to opal_event
This commit was SVN r6328.
2005-07-03 23:09:55 +00:00
Brian Barrett
39dbeeedfb * rename locking code from ompi to opal
This commit was SVN r6327.
2005-07-03 22:45:48 +00:00
Brian Barrett
ccd2624e3f * rename ompi_progress to opal_progress
This commit was SVN r6326.
2005-07-03 21:57:43 +00:00
Jeff Squyres
35c141aef6 While we're moving directories around, move ompi/mpi/runtime ->
ompi/runtime, for consistency and parallel-ness will orte/runtime.
Also remove a few useless #includes along the way.

This commit was SVN r6317.
2005-07-03 12:07:29 +00:00