OK, you're looking from the point of view of squeezing out more
performance.
Whether aio_*() is implemented in user-space or kernel-space probably
makes very little difference.
> 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.
That could be fixed with some decent flags for madvise(2). We could do
with that anyway for other applications.
> 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.
I think the madvise(2) problem needs to be solved in any case.
> 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.
If we get madvise(2) right, we don't need sendfile(2), correct?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu