LWN.net es un gran sitio, no solo "copian y pegan noticias", se las curran, ponen cosas de su parte, etc. Merece la pena suscribirse
Han publicado un historial con las noticias mas importantes del 2004. Lo hacen todos los años. En la sección de Mayo de este año han incluido la noticia del desgraciado accidente que a muchos miembros de augcyl le interesará
Linus acaba de incluir un parche en linux bastante interesante por lo visto: Aumenta el rendimiento de las tuberias. La introducción ha sido totalmente silenciosa, es decir, no se ha comentado ni un solo detalle en la lista del kernel. Pero por lo visto, es muy interesante, porque por lo visto William Lee Irwin ha preguntado que ganancias había, y linus Linus ha respondido con un email, en el que se extraen los siguientes numeros:
On my ppc970 (which Alan correctly points out is not necessarily the best
platform to test), lmbench throughput looks like this:
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem
Mem UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
before:
ppc970.os Linux 2.6.10 753. 1305 550. 1110.3 2051.3 932.3 926.4 2043 1291.
ppc970.os Linux 2.6.10 738. 1596 558. 1099.4 2038.8 936.6 925.0 2033 1288.
ppc970.os Linux 2.6.10 752. 1535 557. 1107.2 2043.5 937.9 932.1 2037 1292.
ppc970.os Linux 2.6.10 750. 1524 556. 1107.5 2046.0 937.2 930.4 2037 1289.
after:
ppc970.os Linux 2.6.10 976. 1594 561. 1110.6 2045.8 934.9 923.6 2039 1288.
ppc970.os Linux 2.6.10 1195 1595 549. 1102.0 2049.0 909.5 930.5 2044 1292.
ppc970.os Linux 2.6.10 1669 1418 507. 1122.9 2051.3 943.4 916.4 2035 1280.
ppc970.os Linux 2.6.10 1472 1612 557. 1092.4 2032.9 932.1 935.1 2030 1281.
ie that's a clear improvement (30-90% higher bandwidth). That's from
having (currently 16) pages of buffers in flight instead of just one.
La primera frase es interesante: "On my ppc970 (which Alan correctly points out is not necessarily the best platform to test)". Es decir, Linus Torvalds ha estado hablando con Alan Cox de estos cambios previamente, sin decir nada a la lista, lo cual no hace mas que confirmar ese dicho de que las verdaderas discusiones de linux no ocurren en la lista, sino en privado muchas veces.
Pero lo más interesante viene despues: "However, I've got a long-term cunning plan, which was the _real_ reason for the pipe changes. I'm finally going to implement Larry McVoy's "splice()" operation". Larry McVoy es el dueño de BitKeeper, y antes de eso ha trabajado en Solaris, Irix, etc; es decir: conoce Unix. Y es tambien el autor de lmbench por cierto (Larry-Mcvoy-bench).
Y si uno busca información sobre ese "splice()" en google se encuentra rápidamente con http://www.bitmover.com/lm/papers/splice.ps. Y si uno empieza a leer el documento se encuentra con esto:
"This document describes a strawman proposal for a new model for I/O in a Unix Operating System. The goals of the new model include low overhead I/O, scatter-gather for zero copy networking to and from disks, async I/O, simple implementation, and compatibility with the existing kernel implementation. The model is fundamentally different than the existing model, but easily provides compatibility with the standard read and write interfaces. If desired, a kernel could move entirely to this model, building the old interfaces on top, somewhat similarly to what Sun did with mmap. If this idea ever lives up to its full potential, it could be as useful as the mmap work.
En otras palabras: Linus Torvalds está planificando mover a Linux a un nuevo modelo de I/O radicalmente diferente al de los UNIX tradicionales con muchas ventajas al "modelo tradicional unix" por lo que dice el documento de Larry Mcvoy. Bastante interesante.
Update: Han salido otros mensajes de Linus explicando que tiene planeado. Por lo visto splice no es más que una manera de "compartir" datos. La diferencia es que tradicionalmente en Unix los datos se copian del espacio de direcciones del proceso al de otro, y así todo el rato, y al final acabas teniendo múltiples copias que son muy costosas, aparte del coste de mantener el espacio de direcciones virtual en el kernel. splice(), tal como yo lo entiendo, es "neutral": No está en el espacio de direcciones de un proceso ni en el del otro. Como consecuencia los datos no se "copian", las copias se eliminan. Por supuesto parece ser simplemente "memoria compartida", pero no, no es memoria compartida...o eso parece. El plan de linus es añadir la llamada al sistema splice() y otra tee(). Lo mejor es que según dice Linus es fácil de implementar, y no se utilizará solo en espacio de usuario, sino como mecanismo dentro del kernel, lo cual tiene sentido porque parece ser un mecanismo de comunicación bastante genérico. Según Linus, ni siquiera es totalmente igual a lo que Larry Mcvoy quería, es algo más "simple", su propia versión del problema, y que nadie ha hecho algo así.:
...So while you can use it to encrypt a file into another file, you could equally easily use it for something like: tar cvf - my_source_tree | hw_engine_encrypt | splice_to_network and the whole pipeline would not have a _single_ actual data copy: the pipes are channels.
Now, imagine using the above in a media server, for example. Let's say that a year or two has passed, so that the video drivers have been updated to be able to do the splice thing, and what can you do? You can: - splice from the (mpeg or whatever - let's just assume that the video input is either digital or does the encoding on its own - like they pretty much all do) video input into a pipe (remember: no copies - the video input will just DMA directly into memory, and splice will just set up the pages in the pipe buffer) - tee that pipe to split it up - splice one end to a file (ie "save the compressed stream to disk") - splice the other end to a real-time video decoder window for your real-time viewing pleasure.
That's the plan, at least. I think it makes sense, and the thing that convinced me about it was (a) how simple all of this seems to be implementation-wise (modulo details - but there are no "conceptually complex" parts: no horrid asynchronous interfaces, no questions about hotw to buffer things, no direct user access to pages that might partially contain protected data etc etc) and (b) it's so UNIXy. If there's something that says "the UNIX way", it's pipes between entities that act on the data.