On Sun, 3 Sep 2000, Lincoln Dale wrote:
> many people (myself included) have been experimenting with zerocopy
> in my case, i've been working on it as time permits for quite a few months
> now, and am about on my fourth rewrite.
> i've found exactly what you state about the bad things that occur when you
> associate zerocopy infrastructure with user-space code. some of the the MM
> tricks required for handling individual pages effectively kills any
> performance gain.
> however, approaching it from the other angle of "buffers pinned in kernel
> memory" can give you a huge win.
The "send data from already pinned buffers" case is different. That is
basically why "sendfile()" exists, and why TUX gets good numbers. Once you
get away from the "zero copy from user space" mentality, and start just
passing kernel buffers around, things look a lot better.
> for the application which prompted me to begin looking at this problem,
> where packets typically go network -> RAM -> network, providing a zerocopy
> infrastructure for (a) viewing incoming packet streams pinned in kernel
> memory from user-space [a sort-of SIGIO with pointers to the buffers], and
> (b) hooks for user-space directing the kernel to do things with these
> buffers [eg. "queue buffer A for output on fd Y"] has provided an immediate
> 60% performance gain.
You really should look into using the page cache if you can: that way you
have a very natural way of looking at it and possibly changing the stream
in user mode with no extra copies for that side either.
I'm not saying that you should necessarily actually go to a "real file",
but the best way of allowing user-space access to things like this is
through mmap(), and if you make it look like the page cache you'll get a
lot of code for free...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:16 EST