Re: Process migration strategy

What I meant is:

every new process is sent to the next node, given a list of n nodes,  
and pretending all nodes have equal available resources.

This does not take into consideration the in-equality of resource  
usage by applications and the inequality of server resource  
configurations (RAM, CPU speed and numbers, etc.). However, given the  
simplicity of implementation, the results should be very satsifactory.

Moshe



On Jul 2, 2006, at 11:34 AM, risc-a6VBIPemKmirG/[email protected] wrote:

> Excuse me if i'm completely off my rocker here...
>
> i've got a bit of experience in "round robin scheduling",
> but i'm wondering if we're talking about the same thing.
> i'm talking about round robin tournament scheduling, where
> you schedule games such that everyone is playing all the time,
> but no-one faces each other twice.
>
> is this of any relation at all?
>
> Julia Longtin <risc-a6VBIPemKmirG/[email protected]>
>
> On Sat, Jul 01, 2006 at 11:42:28AM +0200, Niels de Vos wrote:
>> Hello Moshe and others,
>>
>> as I've started a little python scheduler I'm interrested in the  
>> minimal
>> requirements for such a round robin scheduler. When I find time I
>> happily implement these features. Anybody with thoughts about the
>> subject of process migration/scheduling is welcome to share ideas and
>> thoughts.
>>
>> For now I have a one-master scheduler with:
>> - deputy: migrate a random process away from me (and leave it there?)
>> - remote: 50% chance of accepting the process
>>
>> In detail:
>> - a list of all nodes (with hardware and load details) in the  
>> cluster is
>> constructed (on the master-node)
>> - the master-node asks a remote to accept a specified process (with
>> details from /proc/<pid>/stat)
>> - the remote accepts the process with 50% chance (random)
>> - when accepted, the master-node migrates the process
>>
>> For now there are two deamons. I'm already planning to combine  
>> them into
>> one daemon, which effectively allows all nodes to be a master and
>> migrate processes from any-node to any-node.
>>
>> [ Side thought: a migrated process (from nodeA to nodeB is probably
>> unable to get migrated to a third remote (nodeC) without  
>> interaction of
>> the deputy (nodeA). How would nodeB get the migrated process back to
>> nodeA over /proc/<new-pid>/? Or is the migrated process not available
>> in /proc on nodeB??? ]
>>
>> As said, I'm interrested to hear any thoughts or other comment.
>>
>> Cheers,
>> Niels
>>
>> On Thu, 2006-06-29 at 11:54 -0400, Moshe Bar wrote:
>>> Carl
>>>
>>> Dynamic process migration is a very difficult subject and a  
>>> typical NP
>>> problem. If we had a simple round robin ( as I already pointed  
>>> out elsewhere
>>> in this mailing list) that would be more than enough for a lot of  
>>> use cases.
>>>
>>>
>>> Moshe
>>>
>>> -----Original Message-----
>>> From: openmosix-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> [mailto:openmosix-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf  
>>> Of Carl
>>> Radford (DC0854-IT)
>>> Sent: Wednesday, June 28, 2006 9:27 AM
>>> To: openmosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> Subject: [Openmosix-devel] Process migration strategy
>>>
>>> Hi Moshe (and everybody else),
>>>
>>> What is considered the best strategies to govern process migration ?
>>> I noted that it has been mentioned that even a simple strategy  
>>> such as
>>> round-robin can prove to be effective.
>>>
>>> Has any research/testing been done in this area of om that I can  
>>> draw on ?
>>> In particular, what doesn't work well (and when).
>>>
>>>
>>>
>>> Using Tomcat but need to do more? Need to support web services,  
>>> security?
>>> Get stuff done quickly with pre-integrated technology to make  
>>> your job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> openMosix-devel mailing list
>>> openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>>>
>> -- 
>> Niels de Vos
>> http://nixpanic.net/
>> [email protected]
>
>
>
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> openMosix-devel mailing list
>> openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642