Messages in this thread | | | Date | Wed, 24 Jun 1998 03:11:39 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: Thread implementations... |
| |
On Wed, 24 Jun 1998, Richard Gooch wrote:
> 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
| |