Petite question

• [^]Re: Petite question

  Posté par phenix (page perso, ) le 19/07/2004 à 08:21. (lien). É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 Jean-Max Reymond (Jabber id, page perso, ) le 19/07/2004 à 08:27. (lien). É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 !!!

    --
    CKR Solutions Open Source

    • [^]Re: Petite question

      Posté par 007 () le 19/07/2004 à 08:31. (lien). É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.

      [^]Pas toujours

      Posté par vsin () le 19/07/2004 à 09:09. (lien). Évalué à 8.

      > le hardware est toujours en retard ;-)
      
      J'ai bien note ton smiley, mais ce n'est pas toujours le cas. Les OS mettent souvent du temps a exploiter les possibilites offertes par le Hardware.
      
      Un exemple : Pratiquement tous les serveurs (on est bien d'accord, pas les PC boostes) archi Intel supportent l'installation et l'extraction des cartes I/O a chaud. Quid des OS ? Et combien de temps apres la mise a dispos de la fonctionnalite ?
      
      Contre-reflection : Les utilisateurs en avaient reellement besoin ?
      
      Cordialement
      
      Vsin

      • [^]Re: Pas toujours

        Posté par o°Oo°Oo°o°O°Oo° o°Oo°Oo°o°O°Oo° () le 19/07/2004 à 15:42. (lien). É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 Guillaume Knispel () le 19/07/2004 à 14:02. (lien). É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 Guillaume POIRIER (page perso, ) le 19/07/2004 à 15:07. (lien). É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 mdlh () le 19/07/2004 à 16:44. (lien). É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 Matthieu Moy (page perso, ) le 19/07/2004 à 18:26. (lien). Évalué à 16.

        > 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 capicapio () le 20/07/2004 à 08:46. (lien). Évalué à 1.

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