Linux devient massivement multiprocesseurs

Posté par  (site Web personnel) . Modéré par Sylvain Rampacek.
Étiquettes :
0
19
juil.
2004
Noyau
Après être devenu incontournable dans le domaine des gros clusters (plusieurs centaines de noeuds), voici que Linux devient une référence sur les systèmes massivement multi-processeurs.

En effet, SGI construit un super-ordinateur de 1024 Itanium 2 avec 3 To de mémoire partagée pour le NCSA (National Center for Supercomputing Applications) qui sera exploité par Linux.

Dans un premier temps il y aura 2 noyaux gérant chacun 512 CPU puis rapidement 1 seul noyau pour gérer les 1024 CPU.

Toutes les améliorations apportées au noyau 2.6 concernant le support des architectures NUMA et multi-processeurs dépassent finalement toutes les espérances et sont adoptées très rapidement par les constructeurs.

Il se pourrait que la virtualisation, le futur chantier planifié pour le noyau 2.8, fasse son apparition bien plus vite que prévu. Le Kernel Summit, le Congrès des développeurs du noyau, qui commence demain devrait nous apporter des réponses et planifier les axes de développement pour l'année à venir...

Aller plus loin

  • # Petite question

    Posté par  . Évalué à 2.

    Une machine comme cela, vous avez une idée du prix que cela doit couter ? C'est énorme comme machine, un "top" la dedans doit être impressionnant :)
    • [^] # Re: Petite question

      Posté par  (site Web personnel) . Évalué à 5.

      Moi aussi j'ai une petite question. Comment les developeurs du noyeau font pour savoir que leur code fonctione ?

      Ont t'il un fabriquant qui leur donne accés a une telle machine pour faire leur developement ?
      • [^] # Re: Petite question

        Posté par  (site Web personnel) . Évalué à 9.

        Les développeurs sont des salariés du constructeur SGI et donc un accès privilégié à la machine.
        Maintenant, cas classique, le hardware est toujours en retard ;-) alors tu valides ton code sur une machine qui a beaucoup moins de processeurs, de mémoire et quand le proto devient un petit peu opérationnel, tu testes (et debogues !!!) ton code et aussi le proto !!!
        • [^] # Re: Petite question

          Posté par  . Évalué à 1.

          Et réciproquement, on ne fait pas de hardware aussi cher s'il n'y a pas d'OS déjà développé (sur de petites configs) pour tourner dessus.
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 8.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Pas toujours

            Posté par  . Évalué à 4.

            Si je ne me trompe pas, le hot-plug (branchement à chaud) PCI a été introduit par Compaq et fonctionnait déjà sous Windows NT4 à l'aide d'un logiciel Compaq. Ensuite, la chose a été supporté d'office par Windows 2000.

            Côté fonctionnalité, c'est impressionnant de changer une carte alors que le serveur tourne encore, juste en précisant avant au système qu'il faut arrêter de l'alimenter. Tout le reste du système tourne encore, donc il n'est plus nécessaire de procéder à un redémarrage en pleine période d'exploitation pour changer une carte réseau d'un teaming ou autre ! :-)

            Pour info, les serveurs Compaq sont remarquablement bien faits côté hot-plug et redondance (ventilos, alims, processeurs, banques mémoires, etc.)
        • [^] # Re: Petite question

          Posté par  . Évalué à 2.

          Ouai, si le code marche avec 4, 8, et 16 procs, il y a des chances qu'il fonctionne aussi avec 1024 :p (y a que microsoft pour vouloir faire croire le contraire ;)

          Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
          • [^] # Re: Petite question

            Posté par  . Évalué à 6.

            Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
            En effet, le code fonctionne, mais les problèmes d'échelles font qu'il est nécessaire de repenser certains mécanismes, améliorer la granularité, etc... et tout cela demande beaucoup, beaucoup de temps, et des gens très brillants pour trouver des solutions élégantes à ces problèmes de changement d'échelle.
            C'est ce qui fait que Solaris se vend encore très bien dans les domaines de serveur de multi-processeur pour applications de types transactionnelles (SGDB typiquement) (cf. http://www.sun.com/servers/highend/(...) )
            ... enfin, en voyant cette news, je me demande combien de temps tiendront encore les gros Unix... il ne leur restera pour se démarquer les uns des autres d'axer leur offre sur le hard super fiable (et encore!)
          • [^] # Re: Petite question

            Posté par  . Évalué à 2.

            Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.

            L'une des subtilites est de gerer des informations sur des champs de bits. Forcement a 2 bits par processeurs sur un mot de 32 bits, 1024 processeurs, ca tient pas.

            Les developeurs de SGI ont ecrit un patch pour lever cette limite.
          • [^] # Re: Petite question

            Posté par  (site Web personnel) . Évalué à 10.

            > Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.

            Ouais, quelques subtilités, comme tu dis ;-)

            Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.

            Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.

            Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !

            Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.

            Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !
      • [^] # Re: Petite question

        Posté par  . Évalué à 1.

        A mon avis, ils utilisent des modules qui simulent le fonctionnement d'un grand nombre de CPU.
  • # Scheduling domains

    Posté par  . Évalué à 10.

    Il y a eu des travaux récents dans Linux 2.6 . Le 2.6.0 n'était pas très satisfesant.
    Le 2.6.6 (ou 7?) a introduit "scheduling domains" dont il y a ici une excellente présentation :
    http://lwn.net/Articles/80911/(...)

    La difficulté n'est pas d'avoir plein de CPU mais de les faires travailler en même temps.
    • [^] # Re: Scheduling domains

      Posté par  (site Web personnel) . Évalué à 2.

      Sous linux seul un procesus par CPU ne tourne a l'instant T.

      Donc pour les faire travailler en même temps, je pense qu'il faut qu'il y est autant de procesus ouvert que de CPU.

      Peut etre que je me trompe, je pense que c'est pour ca que la commande "ps aux " donne par exemple apache ouvert plusieurs fois
      • [^] # Re: Scheduling domains

        Posté par  . Évalué à 2.

        > Sous linux seul un procesus par CPU ne tourne a l'instant T.

        Ou thread (du moins avec NPTL, linuxthread fesait des équivalents de fork()).
        • [^] # Re: Scheduling domains

          Posté par  . Évalué à 6.

          Le fait que apache lance plusieurs démons n'a rien avoir avec le nombre de processeurs. Ce sont juste des processus fils qui permettent d'accélerer le service web, c'est transparent pour le navigateur.
          • [^] # Re: Scheduling domains

            Posté par  . Évalué à 2.

            Je vois pas de quoi tu parles.
            Apache 2 mixe les threads et les processus. Du moins lorsqu'il est compilé avec les bonnes options.
            Puis le mode "processus" ne manque pas d'intérêt (typiquement lorqu'un module plante).
            btw : apache augmente le nombre de processus/thread en fonction de la demande. C'est configurable via httpd.conf.
            • [^] # Re: Scheduling domains

              Posté par  (site Web personnel) . Évalué à 5.

              Apache 2, je sais pas, mais si mes souvenirs sont bons, le 1 gère un "pool" de processus : Partant du principe que le fork() est une opération couteuse, il en fait quelques uns d'avance, mais les processus créés sont suspendus jusqu'à une réception de requête HTTP. D'ou les multiples httpd, même quand le serveur ne fait rien.
              • [^] # Re: Scheduling domains

                Posté par  . Évalué à 1.

                C'est une vielle astuce, le pool de ressource:

                memoire, threads, processus, etc...

                Les caches memoire sant dans la ligne des pools:

                tu rapatrie plus que necessaire, en te basant sur le fait que tu as de forte probabilite d'en avoir besoin.
          • [^] # Re: Scheduling domains

            Posté par  . Évalué à -2.

            > Le fait que apache lance plusieurs démons n'a rien avoir avec le nombre de processeurs.

            Ooops. Je viens de comprendre (rapport au début du thread).
            Quoiqu'il en soit une connexion est faite avec ip:port:processus (si mes souvenirs sont bons car c'est vieux). Donc par moment que les thread (même pid) ça peut être insuffisant (rien à voir avec le nombre de processeurs).
      • [^] # Re: Scheduling domains

        Posté par  . Évalué à 2.

        Exactement apache forke à chaque nouvelle connection. Autant de processus que de connections.
      • [^] # Re: Scheduling domains

        Posté par  . Évalué à 1.

        Sous Linux comme sous n'importe quel OS multiprocesseur!
        Ou alors il faudra qu'on m'explique comment il peut y avoir plus de processus qui tournent que de processeurs à un instant T.
        • [^] # Re: Scheduling domains

          Posté par  . Évalué à 1.

          sur des archi hyper scalaire?
          en utilisant des processeurs vectoriel et faires des calculs lineaires avec une surcouche?

          pas la peine de m'indiquer la sortie ---> [-]
  • # virtualisation

    Posté par  . Évalué à 5.

    La virtualisation serait surtout un coup dur pour HP et ses superdôme et aussi pour IBM avec ses mainframe, c'était jusque ici leur chasse gardée.
    Encore que.
    Quand j'y pense, une entreprise ayant des besoins en environnement de travail possède déjà les machines ad hoc (et donc les progs qui viennent avec + compétences etc...).
    Alors quel marché pour de telle machines ?
    Quelle complexité d'administration ? quel seront les outils qui viendront avec ?
    • [^] # Re: virtualisation

      Posté par  (site Web personnel) . Évalué à 10.

      Il existe plusieurs solutions de virtualisation. Celle à laquelle j'ai pensé en écrivant cette news est vserver
      http://www.solucorp.qc.ca/miscprj/s_context.hc(...)
      http://www.linux-vserver.org/(...)

      Cette solution de virtualisation surpasse tous ce qui se fait par ailleurs. Elle est super facile à administrer et nul doute que meme les serveurs de base l'utiliseront.
      Il suffit d'assister à une présentation de vserver pour être définitivement convaincu de l'utilité du concept.
      Il y a plein de serveurs en prod qui utilise déjà cette technologie dont...... linuxfr !
      • [^] # Re: virtualisation

        Posté par  . Évalué à 10.

        Perso, j'utilise aussi les vserver et franchement, c'est super simple à faire.

        De plus, le gain de sécurité est impressionant. Un apache qui se fait avoir, seul le vserver pourra être rootkiter.

        En plus, j'ai des potes qui se connecte à ma machine (IRC and co), bah genre, en cas de quelconque problème, seul ce vserver pourra se être utilisé. L'intégrité de la machine est toujours préservé.

        En plus, dans le cadre de développement de logiciel (libre de préférence ;) ), on peut avoir des machines dans différentes versions. Exemple avec Debian : on peut avoir une machine hôte stable, et avoir une station de développement unstable. On a accès à la dernière version de toutes les librairies et on ne risque pas de mettre en péril l'intégrité de la machine hôte.
        Bref, le pied ;)

        ++
        Ludo
    • [^] # Re: virtualisation

      Posté par  . Évalué à 4.

      Certes, lorsque tu as un mainframe qui fonctionne, tu n'auras pas envie de le changer.
      Ceci étant dit, dans le cadre du recyclage, il est évident que tu choisiras la solution la plus adaptée à ton problème.

      Or, lorsque tu regardes à l'heure actuelle les évolutions, tu te rends compte, que certes le mainframe présente des avantages en termes d'administration. Mais dès lors que tu veux des performances supérieurs et [surtout] de l'évolutivité pour ton matériel/ton OS, la virtualisation est pour toi une/LA solution. Il faut évidemment une structure adaptée à ce changement (la machine citée dans l'article est d'ailleurs l'ancêtre de ces solutions).

      Je crois que la virtualisation pourra et sera adoptée par les entreprises, dans le but de gagner en performance et en évolutivité.

      Ceci étant dit, le principal problème que tu as cité sera bien évidemment, de faire comprendre aux entreprises, lors du renouvellement, que c'est ce genre de machine (enfin, peut-être pas non plus, celle là, car là c'est du spécifique), qui sera l'avenir.

      Enfin bon, c'est mon avis.
      • [^] # Re: virtualisation

        Posté par  . Évalué à 8.

        Je ne connaissait pas vserver (mais chroot oui).
        Il me semble que ce n'est pas tout à fait la même chose. Dessous, c'est toujours le même kernel qui tourne, avec le même espace mémoire etc...
        Mais est ce qu'on peut avoir 2 kernels qui tournent en même temps (et de version différentes) comme cela est permis sur mainframe ? Est ce qu'on peut arrêter (rebooter) un des environnements sans toucher à l'autre ?
        Sinon, à mon sens ce qu'il manque encore à linux (valable pour tout les unix à mon sens) c'est encore la stabilité. En 6 ans de boulot sur mainframe, j'ai du connaitre 3 ipl (redémarrage) et à chaque fois pour une monté en version de certaines parties de l'OS. Tout le reste est upgradé à chaud, en arrêtant seulement la partie concernée. Et puis il y a le pb des compétences. Quand tu as une armée de dev, d 'ingé système et pupitreur formé au mainframe, pas facile de prendre un virage technologique trop brusque pour une entreprise.
        Ca marche, ça a couté cher et on connait bien. Quel décideur prendrai le risque de tout foutre en l'air ? Pour mémoire, les superdôme n'ont pas fait un malheur vu leur prix (3 Millions d'euro la bêbete, je parle pour des systèmes de puissance équivalente à un gros mainframe).
        • [^] # Re: virtualisation

          Posté par  . Évalué à 3.

          User Mode Linux permet justement de faire tourner un noyau différent de la machine hote (par contre au niveau de l'addressage mémoire, ca doit etre confondu)
          • [^] # Re: virtualisation

            Posté par  (site Web personnel) . Évalué à 5.

            Euh pas vraiment, l'espace d'adressage du noyau et celui de l'utilisateur sont différents. Et comme dit le nom de ce projet user-mode-linux: le noyau fonctionne en mode utilisateur. Donc techniquement, ceux sont deux espaces d'adressage différents :-)

            --
            Christophe
            • [^] # Re: virtualisation

              Posté par  . Évalué à 3.

              Sur IA-64, le noyau et l'application sont dans le meme espace d'adressage. Par contre l'application ne peut pas acceder "facilement" aux valeurs de l'espace d'adressage du noyau.

              Il y a plusieurs niveaux de privilege mais l'espace d'adressage est bien le meme.
              • [^] # Re: virtualisation

                Posté par  (site Web personnel) . Évalué à 1.

                Si on parle d'adressage virtuel alors non, sous Linux l'espace d'adressage virtuel d'un processus utilisateur va de 0 à 3Go et l'espace d'adressage virtuel du noyau de 3 à 4Go (4Go == 2^32 , donc sur ia32).

                Mais sinon en effet, mais nous n'avions pas trop spécifié de quoi nous parlions :-)

                --
                Christophe
                • [^] # Re: virtualisation

                  Posté par  . Évalué à 2.

                  s/sous Linux/sous Linux x86 vanilla/

                  Genre sur un noyau fedora tu as 4:4 d'activé (oui c'est tres con)
                  [root@loutre]~# cat /proc/self/maps ~
                  002c7000-002dc000 r-xp 00000000 fd:00 1441971 /lib/ld-2.3.3.so
                  002dc000-002dd000 r--p 00014000 fd:00 1441971 /lib/ld-2.3.3.so
                  002dd000-002de000 rw-p 00015000 fd:00 1441971 /lib/ld-2.3.3.so
                  002e0000-003f5000 r-xp 00000000 fd:00 1441973 /lib/tls/libc-2.3.3.so
                  003f5000-003f7000 r--p 00115000 fd:00 1441973 /lib/tls/libc-2.3.3.so
                  003f7000-003f9000 rw-p 00117000 fd:00 1441973 /lib/tls/libc-2.3.3.so
                  003f9000-003fb000 rw-p 003f9000 00:00 0
                  0079f000-007a0000 r-xp 0079f000 00:00 0
                  08048000-0804c000 r-xp 00000000 fd:00 950317 /bin/cat
                  0804c000-0804d000 rw-p 00003000 fd:00 950317 /bin/cat
                  08f34000-08f55000 rw-p 08f34000 00:00 0
                  f6e42000-f6e7f000 r--p 00aa5000 fd:00 200223 /usr/lib/locale/locale-archive
                  f6e7f000-f707f000 r--p 00000000 fd:00 200223 /usr/lib/locale/locale-archive
                  f707f000-f7080000 rw-p f707f000 00:00 0
                  fef77000-ff000000 rw-p fef77000 00:00 0
                  ffffd000-ffffe000 ---p 00000000 00:00 0

                  Tu peux aussi couper de pas mal d'autres manières et sur les archis 64 bits ca serait tres con de limiter l'espace d'adressage d'un processus a 3Go...
                  http://fxr.watson.org/fxr/source/include/asm-alpha/page.h?v=linux-2(...) 82 ou par exemple
        • [^] # Re: virtualisation

          Posté par  . Évalué à 2.

          Personnellement, en matière de stabilité, j'ai quelques serveurs UNIX sous ma garde.
          J'en ai, mais bon, c'est de la triche, y'a pas souvent d'upgrade, mais, j'en ai avec plus de 2 ans d'uptime. Bref, mo'j'dis, honorable.

          Bref, tout ça pour dire, que les seuls reboot qui sont effectués sont pour des changement de version. Dans le cas présents, je te parle d'OS genre : Digital UNIX, Sun et Linux (entre autres, ...).

          Non, vraiment, je ne comprends pas ce que tu reproches en matière de stabilité aux machines UNIX.
          • [^] # Re: virtualisation

            Posté par  . Évalué à 3.

            Non non, je ne reproche rien à unix.
            Je te crois tout à fait quand tu me parle d'uptime de 2 ans. Mais ça c'est un peu l'exception. J'ai travaillé sur des 10-proc sous HP-UX (des espèce de grosse machine à laver) et ça arrivait tout les 6 mois que la machine plante. Mais bon, faut voir l'utilisation qui en était faite. Cette machine servait de serveur de tests pour une multitudes d'appli en dev, de test avec des 10aines d'utilisateurs etc... 6 Mois d'uptime dans ces conditions c'est tout à fait honorable. Et sur une machine peu sollicité (tout est relatif, peu utilisé pour un serveur unix j'entend), 2 ans c'est tout à fait plausible et même plus. Mais sur mainframe, tu as un environnement de dev, d'integ et de prod (ou plus) sur une seule CPU (voire 2) avec des milliers d'utilisateurs 24h/24h (il ya l'exploitation la nuit qui mouline), et un uptime de 2 ans n'a rien, mais alors rien du tout d'exceptionnel.
            Alors si la disponibilité d'un serveur unix est de 99%, celle d'un mainframe est 99.99% (dans mes souvenirs, IBM garantissait moins de 2 heures d'indisponiblité par an sur ses machines).
            • [^] # Re: virtualisation

              Posté par  . Évalué à 3.

              > Mais bon, faut voir l'utilisation qui en était faite. Cette machine servait de serveur de tests pour une multitudes d'appli en dev, de test avec des 10aines d'utilisateurs etc...

              Le type d'utilisation est très important. Le hard aussi :-)
              J'ai utilisé du Digital Unix avec 8 proc et la fiabilité était impressionnante alors que l'utilisation était "massive" (développeurs/utilisateurs/serveurs).
              Dernier uptime connu (avant de quitter la boite) : 450 jours. Plusieur disques dures ont été changés durant cette période (merci raid5).
              upload en journée était de 6 à 15 !
              Un serveur Web qui tient 2 ans n'est vraiment pas impressionnant pour moi maintenant. Et c'est souvent le signe d'une machine peu entretenue (genre mise à jour noyau non appliquée).
    • [^] # Re: virtualisation

      Posté par  (site Web personnel) . Évalué à 10.

      En fait, toutes les machines IBM (hors grand public) utilise la virtualisation. Sur mainframe (ca fait deja pas mal de temps), les AS400 et maintenant les regatta (sucesseur des R6k) par ex le p690 qui permet d'allouer de la ressource a chaud a des "LPAR" (partition materiel virtuel). Tu aller jusqu'a attribuer des pouilleme de cpu/ram a un LPAR. C'est un peu moin souple pour attribuer des extension (un port PCI n'est pas partageable), mais une machine de base doit en autour d'une trentaine alors qu'elle est limitée a 3 LPAR.

      Donc, y'a encore un peu de temps avant qu'un simple noyau concurrence une machine completement pense pour faire ca.

      Pour info, la virtualisation interesse directement IBM, car les regatta sont livrable en AIX ou en Linux. Sauf que sous Linux, tu peux pas attribuer les elements a chaud...
    • [^] # Re: virtualisation

      Posté par  (site Web personnel) . Évalué à 1.

      quelqu'un pourrait m'expliquer brievement le concept de virtualisation?

      ça permet de faire tourner plusieurs serveurs dans des sortes d'environnements chrooté (mais en mieu je suppose)c'est ça?

      est-ce qu'on peux faire tourner 2 noyaux en même temps (avec usemod linux en plus peut-être ?)

      Si oui, est-ce possible de changer un noyau a chaud (on lance un noyau, on en compile plus tard un autre, on le démarre et on coupe l'ancien...)? Ca permettrais de faire des jolis uptime :)
      • [^] # Re: virtualisation

        Posté par  . Évalué à 2.

        C'est pas aussi FreeBSD qui sait faire de très bonne machines virtuelles à l'aide de la commande jail ?

        Le but est sécuritaire, mais pas uniquement. On peut par exemple créer un jail pour apache, puis le chrooter dans sa prison. Ainsi il n'est pas possible d'attaquer l'OS lui même.

        Linux ne possède pas d'équivalent aussi souple / flexible et facile à manipuler de jail qui n'existe que sur les BSD.
        • [^] # Re: virtualisation

          Posté par  . Évalué à 10.

          Non non on confond un peu tout dans ce thread. Je vais essayer de faire le point vite fait :

          chroot : changement de la racine pour un processus (et donc tout ses fils). Ca ne fait rien d'autre. Avantage en sécurité si le chroot est bien pensé et avec un noyau prévu pour (grsec au hasard pour linux).

          jail : concept de chroot plus poussé. la on ne touche plus uniquement au FS mais aussi aussi au pas mal de structures du noyau. Notament avec des restriction au niveau du reseau, process etc. Ainsi autant un processus dans un chroot peu faire n'importe quoi du point de vue syscall, FreeBSDverifie non pas l'uid 0 mais l'uid 0 et si le process est dans une jail. Avantage : sécurité, et souplesse d'administration (on peut laisser une jail a un client qui a un root sur la machine). Inconveniant : ce n'est pas de la virtualisation, le DoS est tres facile etc.

          user mode linux: permet de faire tourner un linux dans un linux dans un linux. En gros ceci permet a un noyau d'utiliser comme architecture non pas le hardware mais un noyau. Tres couteux en performance et utile uniquement pour le debug. Ca n'apporte rien dans la virtualisation ou tres peu pratique. Aucun controle, impossibilite de toucher au noyau qui s'addresse au materiel. Bref ce n'est pas sont but.

          vserver : je connais mal, mais le principe est dans l'idee des jails. Un seul noyau, que plusieurs sous environements utilisent. Par contre le controle des ressources a l'air d'etre plus abouti (inexistant avec les jails actuelles) avec notament des limites sur les processus, la memoire, le disque, le temps CPU. Reste a voir si c'est correctement implémenté on a souvent des surprises :-)

          On reste bien loin des UNIX proprio avec toutes ces solutions. Mais c'est un axe de developpement interessant. D'ailleur FreeBSD a toujours la network stack virtualization de marco Zec dans les cartons qui ne demande qu'a etre developpe :-)

          Note : Ainsi il n'est pas possible d'attaquer l'OS lui même.

          Tout ne repose que sur un seul noyau (comme toutes les solutions presentés ici) donc une faille dans le noyau compromet la machine en entier. Vu le nombre de faille locale trouvées et trouvables... De plus les jails ne sont pas faciles a manipuler il s'agit d'ailleur d'un axe de developpement et de reecriture. Dans l'etat actuel des choses c'est trop ou trop peu. Avec une meilleure integration de MAC la dedans on pourrait faire de jolies choses amha.
      • [^] # Re: virtualisation

        Posté par  . Évalué à 1.

        >>Si oui, est-ce possible de changer un noyau a chaud (on lance un noyau, on en compile plus tard un autre, on le démarre et on coupe l'ancien...)? Ca permettrais de faire des jolis uptime :)

        Ca kexec permet de le faire, ou du moins de s en approcher, par contre pour ton uptime...
        - article d ibm developerWorks: http://www-106.ibm.com/developerworks/linux/library/l-kexec.html(...)
        - depeche (assez recente) sur linuxfr: http://linuxfr.org/2004/05/18/16263.html(...)

        voila voila...
        • [^] # Re: virtualisation

          Posté par  . Évalué à 4.

          Comme indiqué dans les precedentes depeches kexec ne permet pas de changer son noyau a chaud. Ca permet d'eviter le reboot materiel et d'attendre longtemps... Tout l'executif lui est perdu le terme ne s'applique donc pas amha.

          Dans un article sur DTrace les mecs de SUN parlent de 2h pour booter un SunFire 15k y'aurait un gain appreciable.
          • [^] # Re: virtualisation

            Posté par  . Évalué à 5.

            >> Comme indiqué dans les precedentes depeches kexec ne permet pas de changer son noyau a chaud.
            pour ca que j avais dit "ou de s en approcher"

            >> Tout l'executif lui est perdu
            je n ai pas testé kexec, je donais juste ces liens a titre informatifs,en d autre termes j essayais juste de donner des pistes pour un truc que je connais a peine donc fallait s attendre a quelques coquilles :) Peut etre qu une utilisation couplé au suspend to RAM permettrait conserver cet executif, theoriquement ca a l air fesable (avec peut etre quelques bidouilles), apres je peux pas t en dir plus...
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Documentations ?

    Posté par  . Évalué à 3.

    Existe-t-il des documentations sur l'utilisation de deux noyaux en même temps, pour plusieurs CPU ?
  • # Oui bon....

    Posté par  (site Web personnel) . Évalué à 6.

    Combien de FPS à Doom 3 avec tout ça ?
    • [^] # Re: Oui bon....

      Posté par  (site Web personnel) . Évalué à -2.

      Ah, mais faut d'abord installer le driver nvidia ...

      Quoique, non, c'est SGI donc C pas du nVidia
      Lynchez-moi lynchez-moi lynchez-moi ....
      • [^] # Re: Oui bon....

        Posté par  . Évalué à 1.

        > Quoique, non, c'est SGI donc C pas du nVidia

        Vous m'arrêtez si je me trompe mais il me semblait qu'aux premières heures, SGI et nVidia avaient travaillé ensemble sur les drivers Linux (à l'époque des GeForce). Il me semble que c'était parce que SGI voulait utiliser des GeForce à la place de leurs cartes (plus chères et finalement aussi puissantes).

        Mais bon, je dis ptet une ânerie là...
        • [^] # Re: Oui bon....

          Posté par  . Évalué à 2.

          SGI c'est eux qui sont responsables de OpenGL, donc forcément, ça a un lien avec les drivers Nvidia qui sont des drivers OpenGL... :-)
  • # 2 noyaux !?

    Posté par  . Évalué à 2.

    Comment ça marche avec 2 noyaux ? Comment ils font au boot, comment les tâches se partagent... ?
    • [^] # Re: 2 noyaux !?

      Posté par  . Évalué à 4.

      Et avec acpi, longrun, swsusp, et laptop-mode il vont pouvoir économiser pas mal d'énergie.
    • [^] # Re: 2 noyaux !?

      Posté par  . Évalué à 1.

      Avec ce type de becanes avec plein de processeurs, il est souvent (voire toujours) possible de répartir les ressources et de les grouper sur plusieurs machines.
      En gros, tu peux jouer au lego virtuel et créer plusieurs machines plus petites qui seront vues comme des machines autonomes (meme si, physiquement, elles sont dans le meme boitier)

      Par exemple, les grosses SUN (style E6500 & co) font ca depuis des temps immemoriaux.

      Evidemment, l'archi hardware est developpé spécifiquement pour ca.
      • [^] # Re: 2 noyaux !?

        Posté par  . Évalué à 1.

        C'est même ce qu'on appelle de la virtualisation.

        Ce qui existe effectivement sur les gros Sun (E10k, SF15k et petits frères), mais aussi HP (Superdome), Alpha (Galaxy), IBM (p690 Regatta et p670), IBM zSeries (virtualisation matérielle et logicielle), etc.

        Tu peux même le faire sur ton PC (virtualisation logicielle) avec VMWare ou les Vserver (http://www.linux-vserver.org/(...)).

        Et mon petit doigt me dit que ça va arriver en matériel sur les serveurs PC d'ici peu de temps.
  • # ça tombe bien

    Posté par  . Évalué à 0.

    avec la sortie de Doom3...!
  • # Plus d'infos sur Altix

    Posté par  (site Web personnel) . Évalué à 8.

    La lecture du communiqué de presse de SGI http://www.sgi.com/newsroom/press_releases/2004/july/ncsa.html(...) apporte plus d'infos sur la bête.
    Entre autres elle aura une capacité de stockage de masse de 370 To.

    Ce monstre devrait servir à faire des simulations sur l'évolution de l'univers. Moi qui pensais naïvement que tout le monde connaissait déjà la réponse...
  • # et le cpu MIPS ?

    Posté par  (site Web personnel) . Évalué à 2.

    Je me pose une petite et futile question: pourquoi on-t-ils choisi le processeur Itanium plutôt qu'un MIPS ? Demande du client, supériorité technologique, meilleur support du multiproc ?

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: et le cpu MIPS ?

      Posté par  . Évalué à 2.

      Le NCSA n'en est pas a son premier Itanium. Ils ont deja un cluster et pour avoir parle avec certain d'entre eux, ils ont l'air d'en etre assez content.

      Apres il me semble qu'effectivement que l'Itanium se debrouille assez bien dans un environment multi-proc.
    • [^] # Re: et le cpu MIPS ?

      Posté par  . Évalué à 3.

      Fait un tout sur spec.org et tu comprendras très vite !!!
      Le meilleur MIPS est actuellement 4 fois moins performant que le meilleur Itanium, et toute la statégie de SGI, qui est en situation financière relativement difficile et n'a pas les moyens de supporter les frais astronomique de R&D pour un CPU performant, est de lentement mais sûrement switcher sa gamme des MIPS aux Itanium....et de Irix à Linux !!!
  • # CPU dans les Mainframes

    Posté par  . Évalué à 0.

    Quelqu'un pourrait-il m'éclairer sur l'architecture processeurs des Mainframes...et ou il serait possible de trouver de la doc dessus...
  • # Du plus petit au plus gros

    Posté par  . Évalué à 2.

    il est rigolo de constater que la machine s'appelle Cobalt, du même que les plus petits systèmes linux (en leur temps)...
  • # Petite erreur

    Posté par  . Évalué à 1.

    D'après l'autre article, je crois que c'est 1024 et pas 10240.
    De toutes façons, ça me parait plus réaliste.
    Quoique 10240, ça le ferait surement! :)

    A+

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.