> This is the IPC case - CGI to web server. I/O-Lite accomplishes this one
> by mapping fragments into the destination's memory space. This means at
> least a TLB flush, possibly one for each page (or smaller!) of the data
> the CGI is pumping out.
You take the TLB flush a few times, not every operation. See the bit
about acls and such -- they set up a pool of shared pages between the
processes which are reused. You should look at the paper again -- there
are various subtleties in there.
> though. Apache maps entire files at once and keeps a cache of file
> mappings to minimize this.
Apache doesn't have a cache, it can't do an efficient dynamic cache as a
multiprocess server... (if you find a solution that works tell us ;)
> A combination of this and sendfile(2) or lm's splice (which has a lot in
> common with this scheme) might actually be able to do the trick. If we do
> the IPC memory mapping lazily (or just do a copy), applications that are
> performance sensitive (like our web server) can do a sendfile. The kernel
> can then move the IO fragments around internally and the mapping or copy
> for userspace can be avoided. Ingo's point about the very dynamic nature
> of CGI pages makes this endeavor rather questionable though.
Not all data originates in the kernel -- the TCP-checksuming tricks don't
apply to data originated from userland.
It's perfectly valid for a program to dynamically generate a bunch of
content in memory which is used over and over... and the io-lite stuff
transparently makes this work. With sendfile()/etc I'd have to write this
to disk first to fool the kernel into TCP-checksum caching.
Dean
-
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/