Messages in this thread |  | | | Date | Wed, 3 Mar 1999 10:50:17 -0600 (CST) | | From | Oliver Xymoron <> | | Subject | Re: OSDI paper - IO-Lite: A Unified I/O Buffering and Caching System |
| |
On Wed, 3 Mar 1999, Jim Gettys wrote:
> 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/
|  |