openmosix, migration de processus

openmosix, migration de processus - Divers - Linux et OS Alternatifs

Marsh Posté le 24-02-2005 à 01:35:58    

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.

Reply

Marsh Posté le 24-02-2005 à 01:35:58   

Reply

Marsh Posté le 24-02-2005 à 14:17:23    

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

Reply

Marsh Posté le 24-02-2005 à 14:33:39    

darksword a écrit :

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é)

Reply

Marsh Posté le 24-02-2005 à 14:52:44    

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.

Reply

Marsh Posté le 24-02-2005 à 14:54:10    

Reply

Marsh Posté le 24-02-2005 à 15:09:35    

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 :)

Reply

Marsh Posté le 24-02-2005 à 15:15:01    

darksword a écrit :

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.


 
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 ...

Reply

Marsh Posté le 24-02-2005 à 16:12:52    

darksword a écrit :

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.


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 :o ?

Reply

Marsh Posté le 24-02-2005 à 16:16:11    

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

Reply

Marsh Posté le 24-02-2005 à 16:21:10    

Taz a écrit :

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.

Reply

Marsh Posté le 24-02-2005 à 16:21:10   

Reply

Marsh Posté le 24-02-2005 à 16:21:44    

y a écrit 'distribuée' ?

Reply

Marsh Posté le 24-02-2005 à 16:22:28    

yaisse

Reply

Marsh Posté le 24-02-2005 à 16:26:43    

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)

Reply

Marsh Posté le 24-02-2005 à 16:45:42    

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) ?

Reply

Marsh Posté le 24-02-2005 à 16:47:17    

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

Reply

Marsh Posté le 24-02-2005 à 16:49:42    

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.

Reply

Marsh Posté le 24-02-2005 à 16:51:32    


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


Message édité par ++fab le 24-02-2005 à 16:52:08
Reply

Marsh Posté le 24-02-2005 à 16:57:50    

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 ?

Reply

Marsh Posté le 24-02-2005 à 17:04:48    

darksword a écrit :

la mémoire partagée est par exemple les données partagées entre les threads issus d'un même processus.
?


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...

Reply

Marsh Posté le 24-02-2005 à 17:05:59    

cette mémoire distribuée m'intrigue

Reply

Marsh Posté le 24-02-2005 à 20:15:46    

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 ???

Reply

Marsh Posté le 24-02-2005 à 20:37:52    

darksword a écrit :


Il y a des librairie spécifiques (jcluster, marcel, ...) qui permettent de créer des threads en contexte utilisateur, donc qui peuvent migrer.


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

darksword a écrit :


Pour la mémoire distribué, ben elle est distribué quoi :)


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 ?


---------------
-@- When code matters more than commercials -@-
Reply

Marsh Posté le 24-02-2005 à 20:48:25    

Citation :

++fab >> tu veux faire quoi avec openMosix ?


joujou :D 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 ?
 

Citation :

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.


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 ?

Reply

Marsh Posté le 24-02-2005 à 20:59:12    

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 :D 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.


---------------
-@- When code matters more than commercials -@-
Reply

Marsh Posté le 24-02-2005 à 21:56:33    

Citation :

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à.


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.
 

Citation :

Si tu veux faire joujou avec ce genre de système, je vais faire un peu de pub :D 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.


ç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  :o

Reply

Marsh Posté le 24-02-2005 à 22:15:34    

++fab a écrit :


ç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  :o


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


---------------
-@- When code matters more than commercials -@-
Reply

Marsh Posté le 24-02-2005 à 22:22:42    

je vais attendre alors :)

++fab a écrit :

monkey kézako ???


hein c'est quoi monkey ? :sweat:

Reply

Marsh Posté le 25-02-2005 à 09:12:30    

manu025 a écrit :

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


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

Reply

Marsh Posté le 25-02-2005 à 09:35:39    

darksword a écrit :

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


OpenSSI et Kerrighed


---------------
-@- When code matters more than commercials -@-
Reply

Marsh Posté le 25-02-2005 à 09:54:09    

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

Citation :

General Limitations
 
    * Cannot add or remove a node on a running Kerrighed cluster.
    * A node failure makes the whole cluster unavailable.
    * No global device management.


 
Pour OpenSSI, je vois ça :

Citation :

threaded processes migrate as a group


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.

Reply

Marsh Posté le 25-02-2005 à 10:11:12    

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 ?


---------------
-@- When code matters more than commercials -@-
Reply

Marsh Posté le 25-02-2005 à 10:29:06    

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 :)

Reply

Marsh Posté le 25-02-2005 à 10:48:45    

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..


---------------
@+
Reply

Marsh Posté le 25-02-2005 à 11:00:12    

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 ?

Reply

Marsh Posté le 25-02-2005 à 11:55:08    

francoisp31 a écrit :

Les applis non specifiques clusters partagent bien et les threads migrent bien....


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


Message édité par ++fab le 25-02-2005 à 11:56:20
Reply

Marsh Posté le 25-02-2005 à 12:03:17    

darksword a écrit :

<...>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 <...> :)


 
coder en Java pour rechercher la perf, ça me parait une douce hérésie :sweat:
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 ...)

Reply

Marsh Posté le 25-02-2005 à 12:35:47    

++fab a écrit :

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


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


---------------
@+
Reply

Marsh Posté le 25-02-2005 à 13:40:25    

++fab a écrit :

coder en Java pour rechercher la perf, ça me parait une douce hérésie :sweat:
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 ...)


 
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 ?

Reply

Marsh Posté le 25-02-2005 à 15:26:27    

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 :o


Message édité par ++fab le 25-02-2005 à 15:32:58
Reply

Marsh Posté le 26-02-2005 à 23:42:22    

up

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed