Sé que splice() está diseñado para copia cero y usó el búfer de canalización del kernel de Linux para lograrlo. Por ejemplo, si quisiera copiar datos de un descriptor de archivo (fp1) a otro descriptor de archivo (fp2), no necesitaba copiar datos del "espacio del núcleo->espacio del usuario->espacio del núcleo". En su lugar, simplemente copia datos en el espacio del núcleo, el flujo será como "fp1 -> pipe_read -> pipe_write -> fp2". ¿Y mi pregunta es que la dosis del kernel necesita copiar datos entre "fp1 -> pipe_read" y "pipe_write -> fp2"?
La Wikipedia dijo que:
Ideally, splice and vmsplice work by remapping pages and do not actually copy any data, which may improve I/O performance. As linear addresses do not necessarily correspond to contiguous physical addresses, this may not be possible in all cases and on all hardware combinations.Ya rastreé la fuente del kernel (3.12) para mi pregunta y descubrí que el flujo entre "fp1->write_pipe", al final llamaría kernel_readv() en fs/splice.c y luego llamaría "do_readv_writev()" y finalmente llamado "aio_write ()"
558 static ssize_t kernel_readv(struct file *file, const struct iovec *vec, 559 unsigned long vlen, loff_t offset) //*vec would point to struct page which belong to pipeEl flujo entre "read_pipe -> fp2" al final llamaría "__kernel_write()" y luego "fp2->f_op->write()"
430 ssize_t __kernel_write(struct file *file, const char *buf, size_t count, loff_t *pos) //*buf is the pipe bufferY pensé que tanto "aio_write()" como "file->f_op_write()" realmente realizarían una copia de datos, entonces, ¿empalme() realmente realiza una copia cero?
Según entiendo splice(), leerá páginas de fd1 y la MMU mapeará estas páginas. La referencia creada por el mapeo se colocará en la tubería y se entregará a fd2. No se deben copiar datos reales en el proceso, siempre que cada participante tenga DMA disponible. Si no hay DMA disponible, debe copiar los datos.
Lo más probable es que el splice funcione como copia cero (no hay una garantía sólida para eso, pero es casi seguro que funciona de esa manera para cualquier hardware razonablemente reciente). Siguiendo estrictamente los documentos, necesitaría llamarlo con SPLICE_F_MOVE para que no se hagan copias reales, pero no veo cómo tendría que hacer una de cualquier manera siempre que haya soporte DMA (que es una suposición bastante justa).
Lo mismo no es necesariamente cierto con vmsplice involucrado ya que (o un splice sucesivo) solo funciona sin copia si se proporciona el indicador SPLICE_F_GIFT (y en este caso, puedo ver cómo no funcionaría de otra manera, ya que el "descriptor de origen" es la memoria principal) pero este indicador está roto en algunas y no es compatible con otras versiones de Linux, y está mal documentado en la parte superior.
Por ejemplo, no está claro qué hacer con la memoria después. La documentación solía decir que no se le permite tocar la memoria regalada nunca más, esto se reformuló ligeramente recientemente, pero no es menos ambiguo. No está claro qué será de la región de la memoria. Siguiendo la documentación, tendría que perder la memoria. Parece que no hay un mecanismo de notificación que le indique cuándo es seguro liberar la memoria o reutilizarla.
aio_write es la implementación del área de usuario (Glibc) de E/S asíncrona que utiliza subprocesos y la llamada al sistema de write . Esto normalmente realiza al menos una copia del espacio del usuario al espacio del kernel.