Re: [openMosix-general] Problems with automigration

[Moshe B. <moshe@Moelabs.com>]

Otto,

The processes of a Matlab instance using shared memory cannot migrate
because the Linux kernel has no way to share memory between nodes.

If you launch processes with runon then they start there directly without
migrating and their shared memory segments are created on the remote node
directly.

Moshe


On Tue, 30 Jul 2002, Klingesberger Otto wrote:

> Hello,
>
> Last week we have implemented a 16 node OM-cluster (2.4.18-1
> 1 GB mem, AMD 1900).
> The cluster will be used for some matlab jobs.
>
> Now the problem:
>
> If i start 16 jobs with "runon nodenr matlab ..." (with
> nodenr 1..16) all jobs are starting and after a short delay
> all processes use 99 % cpu on their nodes.
>
> But if i do not lock them on specified nodes and want
> openMosix to choose the best node, the jobs only use
> a few nodes and cpu time degrades to a few percent.
> Also the network itself gets overloaded. (NFS timeouts,
> ssh sessions stall ...).
>
> I also did some tests with "slowdecay" and "cpujob",
> but id didnt help.
>
> OpenMosix is working perfectly with nodelocked jobs, but we need
> the feature of migration to the best node, because we can not predict
> the type (cpu/io bound) and number of jobs, the users want to start
> in the future.
>
> Any hints ?
>
> Is it possible to activate some sort of logging,
> when a process migrates ? (Beside the kernel weeee
> and woooo :-)
>
> TIA
> Otto Klingesberger
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code1
> _______________________________________________
> openMosix-general mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-general
>