> Why bother with sendfile() if you have aio_*() available? sendfile()
> is a trivial wrapper to aio_*().
aio_* are user space. So they use either read() or mmap() to get the data
to be sent... which are the methods already available to apps, so there's
no need to use aio.
read() is painful because it involves an extra copy of the data --
although that could be optimized by putting page flipping into the kernel,
and writing the app to ensure it uses page aligned buffers. read() cannot
exercise the hardware to its fullest.
mmap() is painful when your working set exceeds the RAM available because
it doesn't readahead more than a page. read() does 4 page readahead (I
think these are the numbers), and outperforms mmap() in this situation.
DavidM gave me a patch to improve things... but they're still not quite at
the level that read() is at... and read() isn't at the level the hardware
can handle.
sendfile() could be used to give a huge hint to the kernel about the
nature of the data to be sent... so the kernel can make better judgements
about when to readahead, and what to throw away in low memory situations.
It isn't terribly necessary if the mmap() readahead problem is solved, but
DavidM made it sound like that was an icky problem to solve.
The main reason you want mmap() (or sendfile()) over read() is to be able
to perform single-copy and zero-copy TCP. read() with page-flipping is
another way to do it, but I really don't know the difficulty.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu