Distributed Process Scheduling Algorithm

[Nitin Varyani]

if you say "no network connections" and "no open files",
the problem gets a lot easier - but also quickly devolving into a
master's thesis research project rather than anything useful....

Actually it is a master's thesis research project as of now. I am ready to
boil down to the most basic implementation of distributed linux kernel.
Assume there is no network connection and no open files. We can drop even
more assumptions if it becomes complicated. Once this basic implementation
is successful, we can go ahead with a more complicated version. The next
task is to integrate the migration code in the linux kernel. What is the
most easy way of implementing it.

On Tue, Feb 16, 2016 at 10:05 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Tue, 16 Feb 2016 09:42:52 +0100, Dominik Dingel said:
>
> > I wouldn't see things that dark. Also this is an interesting puzzle.
>
> Just pointing out *very real* issues that will require solution, unless
> you add strict bounds like "cannot be using network connections".
>
> Heck, even open files get interesting.  How do you ensure that the
> file descriptor returned by mkstemp() remains valid? (The *really*
> ugly case is programs that do a mkstemp() and then unlink() the result,
> confident that the kernel will clean up when the process exits, as
> there is no longer a file system object to reference....
>
> Of course, if you say "no network connections" and "no open files",
> the problem gets a lot easier - but also quickly devolving into a
> master's thesis research project rather than anything useful....
>
> Bottom line:  Don't even *think* about changing the scheduler etc
> until you have a functional way to actually move the process.  Doesn't
> matter if you use a kvm approach, or containers, or whatever - if
> you can't do the migrate, you can't even *test* your code that decides
> which process to migrate.....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160217/fee2dfc8/attachment.html