[SMPI] (FIRST PATCH) Remove 'getPid() - 1' arithmetic from SMPI.
THIS COMMIT WILL NOT BUILD PROPERLY OR HAS FAILING TESTS. I decided to split up
a huge commit into several logical chunks in order to make things easier to read.
The 'getPid() - 1' expressions were the (temporary) replacement for smpi_process()->index() but it's better
to remove it completely: This is often confused for being an MPI rank
although it is not (ranks depend on the communicator in use).
Also, process id 0 is exclusively the maestro so we should not artificially
pretend we start counting from 0 when we're clearly not. So now we don't have to
say that 'process with id 1 has index 0'.
This patch substitutes almost exclusively 'getPid() - 1' computations with
just 'getPid()'. There are a few other replacements, especially in the smpi_win.cpp,
where former commits introduced logically wrong usage of 'comm_->rank()'.
The next few commits after this should also deal with a similar problematic.'
[SMPI] Remove usage of index() in smpi_pmpi_coll.cpp
We can just use comm->rank() instead. Note that usage of the index()
function was also incorrect: This would not have worked when the
communicator is not MPI_COMM_WORLD as the index() function always returned
Actor.pid-1 (as set in the Process::init() function)
This is a huge commit and removes the index() function from
smpi::Group and replaces it with an actor() function.
The index was basically just Actor::getPid()-1 and doesn't need
to be saved. It was also often used for the privatization segment
(to know where it was stored) but that is no longer required.
This commit breaks the following tests:
The following tests FAILED:
181 - smpi-msg-masterslave-thread (Failed)
182 - smpi-msg-masterslave-ucontext (Failed)
183 - smpi-msg-masterslave-raw (Failed)
To fix this, many more changes will be required. This will be done in
the next commit. This commit is just there to make sure changes
remain easily understandable (by having small, easy-to-read commits).
I changed the following:
- Remove variable index_to_process_data
- Make process_data a map instead of an array.
- Remove the "index" variable for SMPI instances (no longer needed)
And cleanup the mess that comes with these changes (delete/free, ...)
Frederic Suter [Tue, 23 Jan 2018 11:24:37 +0000 (12:24 +0100)]
Making MSG fade away (part 1)
most of the MSG_host functions already have a sg_host equivalent.
Don't duplicate the code or multiply the layer and use #define in
include/simgrid/host.h to guarantee backward compatibility
Frederic Suter [Mon, 22 Jan 2018 10:39:38 +0000 (11:39 +0100)]
get rid of vm->isMigrating()
There already was an equivalent in the live migration plugin. This
method was only used internally to detect if a VM was destroyed while
it was migrating. This is now useless.
Frederic Suter [Mon, 22 Jan 2018 10:09:30 +0000 (11:09 +0100)]
Close #105
When a VM is shutdown, a signal is triggered which is captured in the VM
live migration plugin. If the VM was currently migrating, it kills the
RX and TX actors and the actor that was used to call sg_vm_migrate in
an asynchronous way. Smart pointers on these three actors are stored
in a new extension of the VM which is created when started a migration.
A test for this feature has been added in
teshsuite/s4u/cloud-interrupt-migration which corresponds to the
scenario described in the issue
Frederic Suter [Thu, 11 Jan 2018 12:40:24 +0000 (13:40 +0100)]
Messing up with VM
- move VM tracing to S4U
- move last functions related to migration to the plugin
- MSG_vm_create is now MSG_vm_create_migratable and tagged
as DEPRECATED (will be removed in 3.21)
- Assume that the live migration plugin is always loaded in JAVA
(because all VMs are create with MSG_vm_create there)
- add a proper destroy function to S4U VMs (shutdown first, then
destroy)
- pimpl_vm_ is now private (with getImpl() as accessor)
- and use the user level interface as much as possible
Conclusion: The MSG_vm interface is now just a dummy wrapper on the
S4U interface and live migration is fully isolated in a plugin. Only
the is_migrating bool remains in VirtualMachineImpl, but is not (and
should not be) accessed or modified from outside the plugin. We can live
with that.