> I believe it will also help the CPU cache case for CGI; it avoids having
> to touch the data again in many operations, which would pollute the cache
> with data that was merely copied in the web server.
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. And on an SMP machine, the hit we take gets a lot
worse. The cost of a TLB hit vs copying a page is probably not a win. It
would be interesting to benchmark to find out where the breakeven point is
though. Apache maps entire files at once and keeps a cache of file
mappings to minimize this.
Because FreeBSD[1] is not really optimized to avoid TLB flushes to the
degree Linux is (remember - it's got fancy zero-copy code in place
already), the TLB hit might not be a big deal, but it is on Linux.
Unfortunately, the TLB thing is probably going to get worse, not better,
with improvements in processors. The tables are getting substantially
larger and the disparity between memory and CPU speeds probably will
probably continue to widen.
I'm trying to figure if there are any ways to avoid changing memory maps
so dynamically. If not for security concerns, we could open a large memory
window at process creation time. Except that window would have to be as
large as the I/O cache pretty much by definition.
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.
[1] I am not a FreeBSD hacker, feel free to correct this
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/