Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 May 2013 23:04:32 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: MPI vs. --fork

On 30 Apr, 2013, at 16:33 , magnum <john.magnum@...hmail.com> wrote:
> My goal is to have MPI and -fork so very similar that a forked run can be resumed with MPI, or vice versa. The contest branch was almost there.

I will start this for real tomorrow but here are some loose plans:

This will happen when an MPI build is actually running on more than one node:
* Early on, it will clear john_main_process for all but node 0.
* When starting a new session, it will reject the --fork option.
* But it will write a fake "-fork=x" entry in the rec file.
* And when resuming, it will ignore any "-fork=x" entry in the rec file. Actually it will demand one but ignore it's original meaning - and it will verify that x == number of nodes and bail out otherwise.

Simple is beatyful. I think the above will basically do the trick (though the devil may be in the details). BTW for combinations like this:

./john -fork=4 -node=5-8/12 ...

in the contest branch, this could also be done with MPI as in:

mpirun -np 4 ./john -node=5-8/12 ...

The contest-branch code for this MPI-specific case is hard to follow. If my unification of MPI & fork goes well, this will now be supported basically just using present core code. Less differences, less maintenance, much more reliable!

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ