Re: oM 2.6, let's get working, todolist ?

Florian Delizy <[email protected]>
Newsgroups gmane.linux.cluster.openmosix.devel
Message-ID <[email protected]>
Carl Radford (DC0854-IT) wrote:
> Hi Florian,
>
> You seem to know what you are doing (or what you want at least :>).
> Don't let this detract you from the kernel, I am desperate for 2.6 too,
> but until you get your to-do list, could you please give me some
> feedback/direction ?
>   
I am not sure I can be the one to give you the best directions, but at 
least I'll do my best
> I have been working on a 2.6 migration daemon for "my toy" cluster,
> but desperately need to know what is required of it in the real world.
>
> At the moment it supports both peer clusters ("volunteer" resources) or
> controller/drone clusters ("do this work", which sounds like what you 
> want).
> Instructions to the kernel to migrate a process are based on current 
> load.
>
>   
Yes, definitely, but this daemon will need some stuff for me to be 
reusable, (at least in my case), here it is:

- an interface to plug a proprietary heuristics (e.g.: plugin 
interface), so that I can develop a software that will inform which task 
should go on which node based on the task knowledge. Since I guess your 
code will be GPL, (unless it is MIT?), I actually have to get a way to 
use it, without actually linking it. Problem is that my company policy 
is not to release the heuristic software thing (they want to own this 
very part of the software I'll develop).
- a full control interface from the rest of the world, allowing to 
blacklist a node, limit a node load average or process number (e.g.: 
informing the migration daemon not to move more than n processes on a 
specific node), those things needs to be node specific (I'll also need a 
way to set it up for the whole cluster, e.g.: a default policy, and a 
per node policy).
- the migration daemon must be able to work in collaboration with some 
other instances of itself, e.g.: you have 4 front nodes that control all 
the cluster, all those front nodes will issue tasks that will be run on 
other computation nodes, so that the migration daemon of all those fron 
nodes will need information on all computation nodes, and must take 
decisions collaborately. IMO, something like a collaborative heuristic 
would work. Each front node is responsible for managing processes it had 
initially issued.
- information must be taken as much as possible directly from the 
kernel, and not stored in the process memory, so that HA can be 
implemented afterwise on this process easily.
- create a task in suspend mode, then move it to a node and wake it up
> The sort of thing that would be of help:
>
> What sort of network (one segment, or multi segment with routing) is 
> required ?   
Single segment, no routing (at least not yet)
> How many cluster nodes in total ?
>   
on our first cluster (development only) around 8 machines, our pre-prod 
development platform around 32 machines, and the final platform can 
handle several hundreads nodes (probably around 700 in a first time, 
then would increase)
> What do you mean by defragmentation ?
>   
For instance, you have 4 computation nodes (A, B, C, D), and one front 
node (M).
A is 20% charged with two tasks taking 10%CPU each,
B is 70% charged,
C is 80% charged,
D is 50% charged with one task taking 20%, the other taking 30%.

All tasks had been created from M.

M wants to create 2 tasks which will be evaluted to 90% and 60% CPU.

Defrag would be taking a task from A to put it on C, decreasing A load 
to 10%, then create the 90% task on A which would then be 100% charged. 
Then take the 20% task of D, put it on B, decreasing D load to 30%, and 
increasing the B load to 70%+20%=90%, then create the task on the D node.

The defrag could have different heuristics, for instance, optimising 
memory usage (to have as much free nodes as possible), dispaching 
equally memory usage (so that all nodes share an average load), and the 
same for CPU consumption. Again, the defrag heuristics must provide a 
way to plug proprietary heurstics to it.

> I have attached the man page to give you an idea of what it does, 
> could you please
> let me know what you think it should do
I had a look at it, it seems a good start

Again, for now I will concentrate on the kernel side (of the force?) for 
development, since I am first of all a kernel developer, but I'll have 
to deal with the user side as well

-- Florian Delizy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.