Re: TLB refill problems again?

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 29 Dec 1998 07:54:03 +1100

Alan Cox writes:
> > The data volume is tiled in memory, so the memory access patterns are
> > somewhat random (though of course the same for each test run). From
> > the earlier responses with the Solaris 2 measurements, I gather the
> > same problem with TLB filling (namely, that it's slow) is happening.
> > Does this sound like a reasonable conclusion? If so, is there
> > something that we can do about it? It's an awful performance suck.
>
> The TLB reloads on x86 are hardware and relatively cheap. Its much more
> likely your problem is cache related than TLB related.

But how? When using the mmap()ed data, it should always have the same
alignment (file starts on a page boundary and volume data starts on a
64 byte boundary). Yet, here is a sample of rendering times on the
dual PPro:
2.0 s kernel 2.1.126 machine up for days, much activity beforehand
2.2 s kernel 2.1.126 machine up for a day or so, little activity b/h
3.3 s kernel 2.1.132 machine up for minutes
2.8 s kernel 2.1.132 ditto

I haven't had time yet to determine if I can't ever get 2.0 s
rendering times with 2.1.132: I need to do some kernel compiles and
kernel tree diffs to stirr up those page tables. My guess is that once
I do that, I'll get 2.0 s rendering times again. Otherwise the
unthinkable has happened: 2.1.132 is screwing up.

Regards,

Richard....

-
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/