On Thu, 25 Jun 1998 10:05:17 -0700, lm@bitmover.com (Larry McVoy)
said:
> In the for what it is worth department, you are venturing into charted
> waters. SGI has done all of these tricks and more for years and I think
> we can learn from their experiences. A few points:
> 3) You can read my writeup of how I thought I/O ought to be done after
> doing it at SGI for a while, it's in
> ftp://ftp.bitmover.com/pub/splice.ps.gz (also splice.ps)
> It's not what I'd call detailed, but it is interesting reading and I'd
> love to discuss the idea with you at length. Stephen Tweedie and I
> started to talk about it at Linux Expo; maybe he has some thoughts
> he cares to share?
Just that on reflection, I still think it's the way to go. sendfile()
just "feels" like a hacked solution to a specific problem.
Unix has always been about providing general tools. We already have
iovecs and the ability to read and write them via readv(fd) and
writev(fd). Extending that to do pull(fd) and push(fd) on iovecs
which stay in kernel space just feels like a natural extension of the
Unix interface, offering true zero-copy performance without
sacrificing any of the control you normally get with read/write.
splice() on its own always felt wrong for the same reason. splice()
as a special case of pull/push feels much better than splice() as the
underlying mechanism.
I can't see any advantage of sendfile() over push/pull other than a
reduction in the number of system calls required to get the job done.
(sendfile will still most likely be implemented as a kernel loop
inside the sendfile syscall, so there is still a scheduling cost if
you use that mechanism despite the fact that the schedule is hidden
within the syscall.)
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu