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/