La raison principale derrière cela est que l'habituel: les E / S sont beaucoup plus lentes que le CPU / RAM. Même si les processus effectuant des opérations d'E / S utilisent DMA (qui décharge la CPU), à un moment donné, ils devront probablement attendre la fin de leurs demandes.
Dans le cas le plus courant d'un disque dur, ajoutez simplement plusieurs applications essayant d'accéder aux fichiers dispersés autour du lecteur, et vous pouvez vous faire un café (thé, peu importe). Avec les SSD, la situation s'améliore, mais même un SSD - qui a un débit mesuré en centaines de Mo / s sur SATA (par rapport à des dizaines de Mo / s d'un disque dur à plateau tournant) et des temps de recherche vraiment négligeables (par rapport aux millisecondes pour une plaque tournante) - peut devenir un goulot d'étranglement.
Le problème que je comprends n'est pas seulement dans les transferts de données eux-mêmes, mais dans la surcharge nécessaire - les E / S sont contrôlées par le noyau, mais ne se produisent que rarement sans espace utilisateur. Ainsi, il peut y avoir beaucoup de changements de contexte, juste à partir des applications en attente d'E / S vérifiant si quelque chose se passe (dépend de la mise en œuvre, bien sûr). Dans le cas des transferts de disques, il peut y avoir plusieurs threads du noyau en compétition pour les ressources ou en attente occupée (ce qui est parfois la stratégie appropriée). N'oubliez pas, par exemple, la copie de données d'une partition à une autre nécessite un système de fichiers moderne pour: savoir où se trouvent les données source, les lire, allouer de l'espace sur le système de fichiers cible, écrire des métadonnées, écrire des données, répéter jusqu'à la fin.
Et si, à un moment donné, votre système commence à échanger (qui a généralement une priorité plus élevée que les E / S normales), la catastrophe est finalisée.
EDIT : Après avoir parlé à certains développeurs de noyau Linux, la situation est devenue un peu plus claire. Le problème principal est le planificateur d'E / S, qui n'a pas beaucoup d'idée sur les E / S à prioriser. Par conséquent, toute entrée utilisateur et sortie graphique suivante partage la file d'attente avec l'activité disque / réseau. En conséquence, il peut également arriver qu'il jette les données de processus mises en cache du cache de pages (par exemple, les bibliothèques chargées) lorsqu'il conclut qu'il peut utiliser le cache de pages plus efficacement sur d'autres E / S. Cela signifie bien sûr qu'une fois que le code doit être exécuté à nouveau, il devra être récupéré à nouveau - former le disque qui peut déjà être sous une lourde charge.
Cela dit, en ce qui concerne le noyau Linux, bon nombre de ces problèmes ont été corrigés récemment (le problème est connu), alors dites 4.4.x ou 4.5.x devrait se comporter mieux qu'auparavant et les problèmes doivent être signalés (généralement les gens du noyau sont contents quand quelqu'un veut aider en rapportant des bogues et en testant).