La razón principal es que lo habitual: la E / S es mucho más lenta que la CPU / RAM. Incluso si los procesos que realizan operaciones de E / S usan DMA (que descarga la CPU), en algún momento es probable que tengan que esperar a que se completen sus solicitudes.
En el caso más habitual de un HDD, simplemente agregue varias aplicaciones que intenten acceder a los archivos dispersos por el disco, y puede prepararse un café (té, lo que sea). Con los SSD, la situación mejora, pero incluso un SSD, que tiene un rendimiento medido en cientos de MB / s en SATA (en comparación con decenas de MB / s de un HDD de placa giratoria) y tiempos de búsqueda realmente insignificantes (en comparación con milisegundos para una placa giratoria): puede convertirse en un cuello de botella.
El problema, según tengo entendido, no está solo en las transferencias de datos, sino en los gastos generales necesarios: la E / S está controlada por el núcleo, pero rara vez ocurre sin espacio de usuario. Por lo tanto, puede haber una gran cantidad de cambios de contexto, solo desde las aplicaciones que esperan la E / S para verificar si algo está sucediendo (depende de la implementación, por supuesto). En el caso de las transferencias de disco, puede haber varios subprocesos del núcleo que compitan por los recursos o la espera ocupada (que a veces es la estrategia adecuada). Recuerde, por ejemplo, copiar datos de una partición a otra requiere un sistema de archivos moderno para: averiguar dónde están los datos de origen, leerlos, asignar espacio en el sistema de archivos de destino, escribir metadatos, escribir datos, repetir hasta que termine.
Y si, en algún momento, su sistema comienza a intercambiarse (que generalmente tiene mayor prioridad que las E / S normales), el desastre finaliza.
EDITAR : Después de hablar con algunos desarrolladores de kernel de Linux, la situación se volvió un poco más clara. El principal problema es el planificador de E / S, que no tiene mucha idea sobre qué E / S debe priorizar. Por lo tanto, cualquier entrada del usuario y la siguiente salida gráfica está compartiendo la cola con la actividad del disco / red. Como consecuencia de eso, también puede suceder que deseche los datos del proceso en caché de la memoria caché de la página (por ejemplo, bibliotecas cargadas) cuando concluya que puede usar la memoria caché de la página de manera más efectiva en otras E / S. Eso, por supuesto, significa que una vez que el código deba ejecutarse nuevamente, tendrá que recuperarse nuevamente, desde el disco que ya puede estar bajo una gran carga.
Dicho esto, en lo que respecta al kernel de Linux, muchos de estos problemas se han solucionado recientemente (el problema se conoce), por lo que digamos que 4.4.xo 4.5.x deberían comportarse mejor de lo que solían y los problemas deberían informarse (en general la gente del núcleo está contenta cuando alguien quiere ayudar mediante informes y pruebas de errores).