Date: Fri, 21 Apr 2000 22:45:50 -0700 (PDT)
From: dean gaudet <dgaudet-list-linux-kernel@arctic.org>
i think that this might drive up TLB activity when you operate at scale
(1000s of tcp sessions), to the point that you don't get a win from the
technique.
...
it's pretty nice -- requires very little memory per-session, great for
handling idle sessions and such... unlike the usual userland buffering
technique which is to allocate a 4k buffer per session and chew ram and
TLB entries.
i will send you a reference to the code when i release it.
I didn't intend it to be used for high performance, many connection
TCP services, it's for bulk data and message passing, that's what
it's good for.
Anyone trying to get top-notch performance out of a userspace http
implementation is insane, the only way to go fast is to stick it all
into the kernel. With the kernel http implementation there are no TLB
issues, there are no "reduce the number of system calls" issues, none
of that crap. For static content you can even generate the reply in
the network software interrupt handler in which you get the request :-)
Now, generically for the TLB entry cost issue, you don't have to use
4k pages to map the socket buffer now do you? Another idea, for a
threaded app we could use a huge shared buffer pool for these TCP
mmaps, using 4MB page mappings, and cut up and allocate pieces of that
to the sockets. This would solve the TLB issue. But all this is
irrelevant, this isn't really the kind of thing I'd expect people to
use the TCP mmap thing for.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 22 2000 - 02:16:42 EDT