Bonsoir,
 
J'expérimente actuellement un cluster openmosix de 2 machines (noyau 2.4.28 patché openmosix). Je suis un peu étonné du peu de migration de processus (la deuxieme machine a pourtant une charge quasi nulle).  
Je précise que j'ai fais le blaireau en compilant quasiment tout les programmes de la premiere machine avec l'option d'architecture -march=athlon-xp (je roule en gentoo). Qu'advient-il d'un tel processus (utilisant l'architecture) qui migrerait sur l'autre noeud, qui lui a un pentium4 ? la mort ? la non-migration (mouais...)? pire ?
 
En tout cas, lorsque je demande manuellement la migration d'un processus, celui-ci n'y va pas toujours, j'en ignore malheureusement la cause étant donné que je ne trouve pas de log   Y a t'il un moyen d'avoir un diagnostic ?
 
Merci pour vos réponses.

t'es sur que open mosix tourne ?
tu teste bien avec des processus (fork) et pas avec des threads ?

 
oui, ça tourne. Et je teste bien avec des processus. Sous quels conditions un processus ne peut-il pas etre migré, c'est la question que je me pose ... (je ne parle pas d'efficacité)

La plupart des processus (tous ?) peuvent migrer.
Je suis quasiment sur que tu n'a pas du lancer le serveur + le client openmosix sur une des 2 machines.

http://dejean.benoit.free.fr/docs/openMOSIX/

pour info (si c'est ton rapport). Ton stage de maitrise à durer combien de temps ?
++Fab : Bien sur les processus ne migre pas si le temps d'execution est réduit < 1-1.5 sec.
Essai de faire un calcul des 100000 premiers nombres premiers en C tu verra ca va migrer

 
Si, tout est bien lancé, et j'observe des migrations quand il y a une bonne charge (typiquement un oggenc ou une compil). mais quand je demande à un process de migrer (à la mimine), des fois c'est oui, et des fois c'est non, et je n'arrive pas à savoit pourquoi
 
Taz> je jette un oeil ...

meme avec la commande migrate ?
 
Taz> J'ai lu la rubrique _facteur limitant la migration_ dans la présentation, et la p.21-22 du rapport. Je bute un peu sur la notion de mémoire distribuée . Pour etre concret, qu'est-ce qui interdit aux process de mozilla de migrer (la shm est OK d'apres le patch). Serais-ce l'acces aux fichiers ? ou cette histoire de mémoire distribuée ?

la SHM
man shmget
man shmat etc
 
c'est une zone mémoire dont le noyau arbitre les accès. Comme elle est commune a plusieurs processus, on ne peut pas avoir le segment de mémoire partagée et le processus sur 2 noeuds différents

 
oué je connais la shm. J'ignorais que mémoire distribuée en était un synonyme    
Les récents patch openmosix ont l'air d'avoir vaincu ce problème en tout cas.

y a écrit 'distribuée' ?

yaisse

ah ben c'est une coquille ou une phrase mal tournée. la mémoire peut pas être distribuée. On s'amusait à faire la génération de knoppix sur le réseau, ça fait un process de 700Mo, c'était marrant de le voir faire le va&vient (joli vague au niveau des graphes utilisations mémoire)

morbleu ! j'ai pris un mauvais exemple, le process "pere" mozilla migre, mais ses fils, eux, ne le suivent pas, et ne veulent rien savoir ! J'appelle la DAS ?
 
sympatique mémoire au fait, je garde sous le coude. Ils ont fait quelle tronche les profs, quand ils voyent successivement mémoire partagé puis mémoire distribée (présentation) ?

la DASS
 
euh rien, dans une présentation tu parles, le support visuel, on s'en fout un peu

attend attend, y a et mémoire distribuée et mémoire partagée. je me souviens plus trop de ce qu'on a voulu dire.

 
ils m'ont dit qu'ils ne pouvait rien faire, c'est quoi ce bordel  

la mémoire partagée est par exemple les données partagées entre les threads issus d'un même processus.
C'est donc une mémoire partagé sur une node.
En C, (et en java) comme les threads sont en contexte noyau tu ne peut pas les faire migrer. D'ou les restrictions (énormes) d'openMosix vu le nombre d'appli qui (ont besoin d') utilise les threads.
Il y a des librairie spécifiques (jcluster, marcel, ...) qui permettent de créer des threads en contexte utilisateur, donc qui peuvent migrer.
Pour la mémoire distribué, ben elle est distribué quoi
 
Pour ton exemple de mozilla, qu'est-ce que tu essaie de faire ? Une applet Java ?

c pas ça ... c'est le segment data dont tu parles.
shm, c'est une zone mémoire que partage des processus.
 
pour mon exemple, je n'essaie rien de faire en particulier, juste d'exhiber un exemple pour lequel une migration ne s'opere pas...

cette mémoire distribuée m'intrigue

J'avance un peu dans ma mélasse :
 
Je viens de me rendre compte qu'il y avait des petits cadenas en face des processus qui ne peuvent pas migrer. On les voit en utilisant le manager d'openmosixview.
Les processus sont marqués "non migrable" car ce sont des clone_vm, ou des monkey + clone_vm.  
Les clone_vm doivent correspondre aux processus légers qui n'ont pas encore eu l'usage d'avoir un nouvel espace d'adressage, et qui utilisent celui de papa. Je suppose donc que ces process non migrable on été créé via clone() + drapeau CLONE_VM. Ils pourront peut etre migré quand ils auront leur propre espace d'adressage... Suis-je à coté de la plaque ?
 
monkey kézako ???

Il existe aussi des OS de type Single System Image qui savent faire migrer des threads
 

La mémoire peut être distribuée et partagée, ça s'appelle de la DSM (Distributed Shared Memory). Le but est d'avoir une mémoire identique à la mémoire d'un SMP sauf que c'est pas un SMP mais un cluster. C'est en gros les NUMA.
 
++fab >> tu veux faire quoi avec openMosix ?

joujou et comprendre en détail comment ça marche et si ça peut m'apporter une station de travail plus réactive. J'avais au départ l'idée de faire baisser les temps de compil (étant gentooiste). A moins de pouvoir configurer emerge pour utiliser distcc ?
 

C'est à ce que je pensais vaguement ... DSM est traduite par mémoire partagée par A. Tanenbaum, ce qui me mettait un gros doute. Openmosix emule une sorte de DSM multiprocesseurs ?

Il me semble que openMosix ne gère dans sa DSM (et encore via un patch que je n'ai pas vu marcher) que les segments de mémoire système V. Donc ce n'est pas complètement une mémoire partagée multiprocesseur mais l'idée est là.
 
Si tu veux faire joujou avec ce genre de système, je vais faire un peu de pub L'équipe où je travaille à élaboré un SSI destiné au calcul hautes perfs. C'est encore relativement instable et ça reste encore niveau recherche mais la version 1.0 va bientôt sortir. Tu peux trouver ça là : http://www.kerrighed.org. Le projet est en GPL, c'est en fait un ensemble de modules qui se chargent sur linux à peine patché. Si tu veux plus d'infos, n'hésites pas à demander.

j'utilise ce patch, et ça a l'air de fonctionner ... mozilla utilise des segments de mémoire partagé sV, et parvient à migrer. Je n'ai par contre aucune idée concernant l'implémentation de cette DSM émulée.
 

ça fonctionne avec un noyau 2.6 ? Si oui, ça m'intéresse, mais une version stable quand meme... Si seulement je pouvais bosser la dedans bordel  

Le portage 2.6 est prévu pour bientôt ... donc faut encore attendre

je vais attendre alors

hein c'est quoi monkey ?

Tu penses à quel(s) système(s) ?

OpenSSI et Kerrighed

Pour Kerrighed, la principale limitation qui me gène est ça :

 
Pour OpenSSI, je vois ça :

Est-ce que je dois comprendre que les threads d'une même application migrent ensembles ?
 
En gros, je suis en stage de master1 dans un labo. Le sujet initial était la mise en place d'un cluster HPC et la parralélisation des programmes. La je suis confronté à plusieurs problèmes :

• Les chercheurs sont pas programmeurs et codent comme des sacs.
• Les pcs qui serviront au clusters sont parfois utilisés pour autre chose.

Pour l'instant, j'ai testé rocks (qui est pas SSI donc qui sert à rien sauf pour répartir des processus), jcluster une librairie java pour les threads qui marche bien mais qui entraine une modification du code et l'utilisation d'une librairie un peu exotique.
Et la je suis en train de tester ProActive, qui est basé sur une répartition P2P.
 
Est-ce que Kerrighed pourrait-être mon ami ? (ie : est-ce que cette limitation d'ajout/suppression de noeud va être résolu "rapidement" ).
 
En tout cas, je pense que je rajoute votre distro à ma todo-list.

darksword>
Pour OpenSSI je ne saurai pas te répondre.
 
Le fait que les chercheurs codent mal, c'est normal. Disons que leur objectifs n'est pas de faire des produits finis mais juste des prototypes illustrant les fonctionnalités intéressantes. Après les labos peuvent embaucher des ingénieurs pour faire cela.
 
Pour Kerrighed, l'ajout/retrait de noeuds est dans la roadmap. Pour la haute dispo il faudra encore attendre pas mal, mais c'est aussi prévu. En tout cas si tu veux essayer, il ne faut pas t'attendre a avoir un système stable qui fera tourner toutes tes applis, il y a encore pas mal de travail d'ingénieurie à faire dessus pour le rendre robuste. Cela dit, pas mal de fonctionnalités sont très intéressantes
 
Sinon tu as essayé openMosix ?

oui, j'ai essayé mais la granularité d'openMosix étant le processus, les chercheurs codant en java et utilisant des threads(même si c'est pas encore forcément le cas), je ne peux au mieux qu'espérer répartir les differents programmes sur la node la moins chargé, mais pas de réduire le temps de traitement des programmes longs en utilisant la puissance du  cluster (ce qui est justement le cas -> résolution de problèmes NP)
 
Pour ce qui est du codage des chercheurs, c'était une boutade, quoique quand même

Je suis assez étonné par tes soucis sous open-mosix car j'ai eut aucun problemes a monter une petite structure 4 machine open-mosix sur (knoppix)à part postgresql qui ne partageais pas ses threads (j'ai su par la suite que c'est normal il faut alors utiliser clusgres pour que ca marche)....
 
Les applis non specifiques clusters partagent bien et les threads migrent bien....
 
Toutefois certains processus ne migrent pas parcequ'ils sont trop "rapides" c'est à dire le temps que ce soit gerer par open-mosix mis en paquets expedié à une autre machine etc... il est déjà terminé et donc ne migrent pas ...
 
Mais pour le reste ça se passe parfaitement...de façons transparente seule config à faire :
fichier MAP et les RHOSTS et le DNS.... c'est tout..

ba j'ai testé avec un prog en C qui calcule les 100000 premiers nombres premiers.
En utilisant des fork() ça migre, en utilisant des pthreads ca ne migre pas.
T'as essayé quel programme exactement ?

pour openmosix  qu'est ce que clusgres dont tu parles plus haut ?

 
coder en Java pour rechercher la perf, ça me parait une douce hérésie
C'est pas vraiment fait pour quand meme ! C++, boost, blitz++ c'est pas mal !  
et dans ce contexte, openmosix ne fera pas aussi bien que si tu distribuais toi meme les calculs avec MPI ou PVM (quoique avec des machines hétérogènes ça se dicute ...)

clustgres est le clustering des bases de donnée postgreSQL.
 
il faut l'ajouter pour que les process postgreSQL puissent fonctionner dans le cluster.

 
Le but n'est pas d'optimiser au maximum un programme pour le faire tourner en temps réel. Il s'agit juste de trouver le meilleur algorithme parmis plusieurs et en ce sens Java convient très bien.
 
francoisp31, est-ce que cela te serais possible de faire un petit test en C pour voir si les threads migrent chez toi ?

pour en revenir à ma question de départ, est-ce que vous pensez qu'il est viable de clusterisé une machine qui a les 3/4 de ces programmes compilés en -march=athlon-xp sachant que l'autre noeud est un pentium4 ? je me suis déja pris 2 plantages sévères : écran figé sur le noeud "athlon-xp". Est-ce que ça peut etre la conséquence d'une instruction processeur inconnue sur l'autre noeud ? ça me parait bizarre mais bon ...
en fait le truc, c'est que j'aurai beau essayer de tout recompiler, il y aura de bonnes chances que j'en oublie qq uns
 
 
et l'autre question en suspend, c'est cette singerie de monkey

up