Forum Linux.noyau Bug dans les accès concurrent du disk

• # ...

  Posté par neologix le 13 juin 2009 à 13:36. Évalué à 8.

  

  Il n'y a pas qu'en anglais que tu as du mal...
  En ce qui concerne ton problème, tu es en train de dire que tu procèdes à des benchmarks en utilisant des outils différents (et que visiblement tu ne maîtrises pas), sur des configurations différentes, et que tu obtiens des résultats différents ?
  Très intéressant, je suis certain que ton analyse va passionner les développeurs du noyau...

  • [^] # Re: ...

    Posté par alpha_one_x86 (site web personnel) le 14 juin 2009 à 11:53. Évalué à 2.

    

    Pour les outils différents je peu pas faire autrement.
    J'utilise la même config matériel. Pas pas le même OS justement pour mettre en évidence les différence de gestion.
    J'ai souvent constaté (et je suis pas le seul) un baisse de débit hdd sous linux et un grosse consommation.
    Que me conseille tu de faire pour faire quelque chose de plus pertinent?

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: ...

      Posté par neologix le 14 juin 2009 à 13:58. Évalué à 6.

      

      Pour les outils différents je peu pas faire autrement.
      
      Rien de t'empêche de faire un programme en C de 10 lignes pour copier un fichier, et de le compiler sous Linux et sous Windows. Au moins, tu sauras ce que fait ton programme.
      
      Pour les testes concurrent j'ai mit 4 programme essayant de faire un lecture parallèle du disk brute. dd if=/dev/sda of=/dev/null pour linux
      
      root@neobox:/home/cf# free -m
total used free shared buffers cached
Mem: 502 383 119 0 122 71
-/+ buffers/cache: 188 313
Swap: 486 0 486
root@neobox:/home/cf# time dd if=/dev/hda2 of=/dev/null count=100K
102400+0 enregistrements lus
102400+0 enregistrements écrits
52428800 bytes (52 MB) copied, 2,61817 s, 20,0 MB/s

real 0m2.622s
user 0m0.069s
sys 0m0.256s
root@neobox:/home/cf# free -m
total used free shared buffers cached
Mem: 502 433 69 0 173 71
-/+ buffers/cache: 189 313
Swap: 486 0 486
root@neobox:/home/cf# time dd if=/dev/hda2 of=/dev/null count=100K
102400+0 enregistrements lus
102400+0 enregistrements écrits
52428800 bytes (52 MB) copied, 0,262924 s, 199 MB/s

real 0m0.267s
user 0m0.057s
sys 0m0.206s
      
      Ca alors, d'un essai à l'autre, la vitesse a été multipliée par 10...
      Bien sûr, on voit tout de suite que le buffer cache a été utilisé pour le deuxième essai, d'où la différence énorme. Tout cela pour dire que j'ai de gros doutes quant à la pertinence de tes tests...
      
      Les performances dépendent de plein de facteurs, l'ordonnanceur d'E/S, le readahead, le FS, l'utlisation du cache...
      
      Il faut savoir que 90% des benchmarks que tu peux trouver sur Internet sont totalement inutiles : il ne faut pas se leurrer, c'est plus complexe qu'il n'y paraît, certaines grandes boîtes emploient des gars dont c'est la spécialité.
      
      Je n'ai rien contre ta curiosité, au contraire, mais il faut bien se renseigner avant de crier au loup, et de vouloir contacter les développeurs du noyau ;-)
      
      J'ai vu que tu développais un équivalent de super-copier sous Linux, ce ne serait pas à cause d'un écart de performances sous Windows et sous Linux que tu te poserais des questions ;-) ?
      Si tel est le cas, je te conseille de regarder ton code avant d'aller poster sur lkml, notamment quand je vois ceci :-)
      
      Hypotése: L'ordonnanceur sous linux ne preampt pas correctement la tache en la mettant sur pause le temps d'avoir les données hdd, mais fait tourner le cpu en boucle.

• # Option de dd

  Posté par Kerro le 14 juin 2009 à 14:57. Évalué à 3.

  

  Ta contribution est notée négativement car il y a beaucoup de fanboys qui ne supportent pas qu'on puisse dire "du mal de Linux". Même pas capables de donner un argument. Ici c'est le consensus mou qui est important.
  
  Avant toutes choses, il semble que la version béta actuelle de Windows soit très performante sur des machines modernes.
  
  Comme maladroitement indiqué plus haut, tu utilises des outils différents (dd et hd tach). Je ne sais pas ce qu'est sensé faire hd tach mais il est probable que ce ne soit pas la même chose que dd. Même si cette différence est minime, cela peut créer des écarts très visibles.
  
  Pour dd, tu devrais utiliser ce genre de chose, cela fera peut-être une différence. Ou pas:
  dd if=/dev/sda of=/dev/null bs=1M >dd1.log 2>&1 &
dd if=/dev/sda of=/dev/null bs=1M >dd2.log 2>&1 &
dd if=/dev/sda of=/dev/null bs=1M >dd3.log 2>&1 &
dd if=/dev/sda of=/dev/null bs=1M >dd4.log 2>&1 &

  note: le signe 'plus grand que' ne passe pas en prévisualisation. Si c'est le cas en affichage normal, remplacer &gt par 'plus grand que'.
  
  Pour avoir tes données:
  killall -USR1 dd
for f in *; do cat $f; echo; done
ou
for f in *; do tail -1 $f; done

  Si tu lances dd de cette manière, tu vas profiter au maximum du cache de ton disque. Les données d'une secteur précis vont être lues une fois, les 3 lectures suivantes se feront à partir du cache.
  Tu pourrais probablement lancer 10 fois dd sans changer le résultat.
  
  Sur une machine avec un SATA2 de 160Go d'il y a 2 ans, ça me donne 4x51 Mo/s vers le milieu du disque (et 4x94 Mo/s au début). Sur une machine avec un SATA2 de 250Go d'il y a quelques mois, ça me donne 4x75 Mo/s vers le milieu du disque. Le tout avec le même noyau agé de 18 mois.
  
  Si tu veux tester avec des lectures décalées, il te faut utiliser l'option skip de dd, avec par exemple un décalage de 10 Go:
  dd if=/dev/sda of=/dev/null bs=1M skip=10000>dd1.log 2>&1 &
dd if=/dev/sda of=/dev/null bs=1M skip=20000 >dd2.log 2>&1 &
dd if=/dev/sda of=/dev/null bs=1M skip=30000 >dd3.log 2>&1 &
dd if=/dev/sda of=/dev/null bs=1M skip=40000 >dd4.log 2>&1 &

  Dans ce cas, le cache disque n'est plus utilisé, et les performances chutent.
  
  Dans ce cas j'obtiens environ 50 Mo/s au lieu de 4x50 Mo/s.
  Et 65 Mo/s au lieu de 4x75 Mo/s
  Par contre le processeur est libre à 99% :-)

• # Re

  Posté par alpha_one_x86 (site web personnel) le 16 juin 2009 à 20:20. Évalué à 0.

  

  J'ai limité la ram à 32Mo sous linux pour faire les testes, donc le cache interviens peu sous linux.
  Oui je m'interroge mais pas à cause de mon copier, juste car tout les testes de tout le monde sous clairement en dessous de ceux de windows quelque soit la méthode (kde, gnome, dd, ...), quelqu'un arrive à faire 100Mo/s d'un hdd à l'autre sous linux alors que sous windows il peu?
  Mais ce qui m'alerte c'est surtout l'utilisation du cpu ET la consommation énorme.
  Avec mon utilitaire de copie même en metant les mêmes FS sous windows et linux l'OS fait trop d'influence dessus (toujours en faveur de windows).
  Et je sais coder un bout de code en Qt pour lire le /dev/sda en brute, mais sous windows le /dev/sda n'hésite pas.
  Je suis plutot pro-linux quoi que asser ouvert au autre OS, mais dans certain cas (dons celui que j'essaye de mettre en évidence) linux utilise du cpu et deviens peu performant la ou d'autre (j'ai pris windows car il est connut) ne le font pas.
  Avec un ofset comme tu l'as sugerai le débit est réparti sur toute les sessions dd, pour chaqu'une d'elle obtiens environs 13.5Mo/s mais un temps de wa dans top de 50% sur un dual core! Alors que quelque soit le bench sous windows j'ai pas des temps cpu aussi gros. Et les temps cpu coller bien avec mes mesures au wattmètre et à l'ampermétre.

  Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • [^] # Re: Re

    Posté par alpha_one_x86 (site web personnel) le 17 juin 2009 à 16:57. Évalué à 1.

    

    Avec une config en ahci cela ne semble presque pas avoir d'influence sur la consommation (5W de plus en full load). Par contre le débit ne sont toujours pas au top.

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

Suivre le flux des commentaires

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