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.
It can be done, for the write case from mmap()'d areas. Just make a
new "vma set hint" type hook, and have tcp_sendmsg() put hints into
the vma's file's readahead information because we know at that point
how much we're about to grab from userspace during this write, and
then filemap_nopage() can use it to perform readahead properly.
Just an idea I had... and it would work. I still think the TLB
thrashing costs of mmap() compared to write() (the kernel has large
PTE's so write is unfortunately almost always faster under Linux) is
going to show up still to some extent, and there isn't much we can do
about that.
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.
Be careful what you talk about. write() is not nearly as difficult to
get zero-copy out of as read(), read() is very difficult without very
specialized hardware and MTU's > PAGE_SIZE as well.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu