> > If you are in the least work for the most bang mode, then you don't do
> > process migration.
>
> But this is Linux, we have an infinite number of monkeys :-)
<rtfl> I havn't had such a good laff off of this list for awhile.. Kernel
Bloat is a concern.. Process migration, and remote execution should end up
being differnt config options..
> > As I've repeatedly said, the dynamic changes are well handled by small SMPs.
>
> Yes, well, okay. But I want to cluster a couple of old 486es...? Oh
> well.
Thats my thought exactly..
> > As has been repeatedly proven, moving an already started process is a lose
> > almost 100% of the time.
>
> Right. Unless somebody just typed shutdown -hnow at the #-rompt.
Sigh, most of the *proof* that I have seen discussed here is regarding
compiling.. Parallel making is probably the most widly used task that
actually gets a big increase from multiple cpus, but it by far not the
only one, or most important one. In a parallel make, migration would be
stupid, the tasks are very short lived so as long as they are placed on
the least loaded computer then it all works.. What about a longer lived
processes, ones that can't easily just save their state and continue
later..
If some fools are playing quake on two nodes of your 4 node
cluster, and you start 4 rc5 daemons, then they are stuck on the other two
boxes.. RC5 isn't a good example because it can easily be restarted.. How
about a 16node cluster, some developer starts a parallel make -j10 and
then someone starts up a long running weather simulation.. It could end up
only running on 6 of the computers, with no hope of moving them.. At least
with migration you would have a chance of moving them..