Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 30 Apr 1999 01:04:22 +0100 (BST) | Subject | Re: 2.2.5 optimizations for web benchmarks? |
| |
Hi,
On Thu, 29 Apr 1999 19:58:31 -0400 (EDT), Greg Lindahl <lindahl@cs.virginia.edu> said:
>> > If I recall correctly, the Sybase folks described this as a major win >> > across many OSes. On the other hand, Apache in particular may not >> > access enough memory to make a huge difference. >> >> Remember, this is TLB flushes, not cache flushes, we're talking about.
> Yes. If Apache isn't accessing that much memory, it doesn't take that > many TLB reloads no matter how often it is flushed. It's only when > you're repeatedly accessing many TLB entries that it's critical to not > flush.
Yes, but the amount of memory you touch is not simply related to the number of TLBs. You're probably going to take an exit path out of the kernel which returns through 3 or 4 levels of function calls all over the kernel. That's not a lot of memory, and it may well already be in cache, but there's a TLB hit for each such access. Then there's the task struct and the stack --- another two. You'll have one for the apache stack, a bunch for the call unwind inside apache and in libc, and more for every single item of data referenced.
In other words, the problem with TLB refill costs is that even a small amount of code/data reference is going to touch many TLBs if there is poor locality of reference, and that's exactly what you expect on a function return from deep in the kernel. The TLB cost is disproportionately high considering the amount of memory actually referenced.
--Stephen
- 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/
| |