Quelle est la progression de l'amélioration des performances / réactivité du système lors des E / S disque élevées?

Chaque fois que le nombre d'E / S disque est élevé, le système a tendance à être beaucoup plus lent et moins réactif que d'habitude. Quelle est la progression du noyau Linux à ce sujet? Ce problème est-il activement travaillé?

Je pense que pour la plupart, il a été résolu. Ma performance sous IO lourde s'est améliorée en 2.6.36 et je m'attends à ce qu'elle s'améliore davantage en 2.6.37. Voir ces articles phoronix .

Wu Fengguang et KOSAKI Motohiro ont publié cette semaine des correctifs qui, selon eux, résoudront certains de ces problèmes de réactivité, pour lesquels ils appellent le bug "le système ne répond plus sous la pression de la mémoire et beaucoup de pages sales / écrites". Andreas Mohr, l'un des utilisateurs qui a signalé ce problème au LKML et testé les deux correctifs appliqués par rapport au vmscan du noyau, a rapporté le succès. Le problème d'Andreas était que le système ne répondait plus complètement (et le passage à un VT a pris plus de 20 secondes) lors de la création d'un système de fichiers EXT4 lorsqu'un disque SSD était connecté via USB 1.1. Sur son système lors de l'écriture de 300M à partir du fichier / dev / zero, le problème était encore pire.

Voici un lien direct vers le bug

Aussi de Phoronix

Heureusement, d'après nos tests et les rapports d'autres utilisateurs Linux cherchant à corriger ce problème, les correctifs vmscan relativement petits qui ont été publiés semblent mieux résoudre le problème. L'interface utilisateur (GNOME dans notre cas) n'est toujours pas fluide à 100% si le système maintient une quantité écrasante d'activité sur le disque, mais elle est certainement bien meilleure qu'auparavant et ce qui se trouve même actuellement avec le noyau Linux 2.6.35.

Il y a aussi l' annonce de la sortie de Phoronix 2.6.36

Il semble que les barrières bloquées disparaissent et cela devrait également améliorer les performances.

Dans la pratique, les barrières ont la réputation désagréable de tuer les performances d'E / S de bloc, au point que les administrateurs sont souvent tentés de les désactiver et de prendre leurs risques. Alors que les opérations de file d'attente étiquetées fournies par le matériel contemporain devraient implémenter raisonnablement bien les barrières, les tentatives d'utilisation de ces fonctionnalités ont généralement rencontré des difficultés. Ainsi, dans le monde réel, les barrières sont implémentées en vidant simplement la file d'attente de demandes d'E / S avant d'émettre l'opération de barrière, avec quelques opérations de vidage lancées pour que le matériel valide réellement les données sur un support persistant. Les opérations de vidage de file d'attente bloquent le périphérique et tuent le parallélisme nécessaire pour des performances optimales; il n'est pas surprenant que l'utilisation de barrières puisse être douloureuse.

Il y a aussi cet article LWN sur la planification équitable des E / S

Je dirais que IO s'est réveillé comme un gros problème à propos de la date de sortie d'ext4 en 2.6.28. Les liens suivants sont vers les versions du noyau Linux Newbies Kernel, vous devriez consulter les sections Block et Filesystems. Cela peut bien sûr être un sentiment injuste, ou juste au moment où j'ai commencé à regarder le développement de FS, je suis sûr qu'il s'améliore depuis le début, mais je pense que certains des problèmes ext4 '' ont amené les gens à regarder attentivement la pile d'E / S, ou il se peut qu'ils s'attendent à ce que ext4 résolve tous les problèmes de performances, puis quand ce n'est pas le cas, ils réalisent qu'ils doivent chercher ailleurs les problèmes.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37