> 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.
> 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.
no there is a much more important difference in favor of sendfile(), it's
the number of 'cursors' active within the system, and the timing of the
movement of these cursors and the coupling between them.
Timing: eg., alone from the memory consumption point of view it's
perfectly possible to sendfile() a 500M file. With pull()+push(), we first
read it into the page cache, then write it out, we go through the page
cache twice.
Coupling: much more important is the cache-utilization argument, if you
sufficiently slice up the work done within sendfile(), you will have the
'freshly read' data still in some of the caches.
while we wont realistically want to sendfile() 500MB files, the caching
argument is true even for smaller files, given the small L1 cache sizes of
most CPUs. Also, sendfile() is pretty much stateless.
are there nontrivial uses of pull() and push()? A sendfile() can be
considered an 'anonymous pull() followed by a push()', subsequent push()es
and pull()s will benefit from the data being already in the page cache ...
also, sendfile() has byte granularity, while pull() and push() (at least
in the proposed form) has page granularity.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu