<div dir="ltr"><span style="font-size:12.8px">if you say &quot;no network connections&quot; and &quot;no open files&quot;,</span><br style="font-size:12.8px"><span style="font-size:12.8px">the problem gets a lot easier - but also quickly devolving into a</span><br style="font-size:12.8px"><span style="font-size:12.8px">master&#39;s thesis research project rather than anything useful....</span><br><div><span style="font-size:12.8px"><br></span></div><div>Actually it is a master&#39;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. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 10:05 PM,  <span dir="ltr">&lt;<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 16 Feb 2016 09:42:52 +0100, Dominik Dingel said:<br>
<br>
&gt; I wouldn&#39;t see things that dark. Also this is an interesting puzzle.<br>
<br>
</span>Just pointing out *very real* issues that will require solution, unless<br>
you add strict bounds like &quot;cannot be using network connections&quot;.<br>
<br>
Heck, even open files get interesting.  How do you ensure that the<br>
file descriptor returned by mkstemp() remains valid? (The *really*<br>
ugly case is programs that do a mkstemp() and then unlink() the result,<br>
confident that the kernel will clean up when the process exits, as<br>
there is no longer a file system object to reference....<br>
<br>
Of course, if you say &quot;no network connections&quot; and &quot;no open files&quot;,<br>
the problem gets a lot easier - but also quickly devolving into a<br>
master&#39;s thesis research project rather than anything useful....<br>
<br>
Bottom line:  Don&#39;t even *think* about changing the scheduler etc<br>
until you have a functional way to actually move the process.  Doesn&#39;t<br>
matter if you use a kvm approach, or containers, or whatever - if<br>
you can&#39;t do the migrate, you can&#39;t even *test* your code that decides<br>
which process to migrate.....<br>
</blockquote></div><br></div>