Messages in this thread | | | Date | Sat, 16 Jan 1999 12:48:37 +1100 | From | Richard Gooch <> | Subject | Re: TLB refill problems again? |
| |
OK, I'm back to chase this problem.
Richard Gooch writes: > 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.
I've done more tests this time with 2.2.0-pre7. If the volume data is mmap()ed, I get 3.8 s rendering times (single thread on an SMP machine). If the volume data is malloc()ed, I get 5.9 s rendering times. The volume data is at an offset of 176 bytes in the file, hence the start of the mmap()ed array should be 176 bytes offset from the first page.
I really don't see how cache effects can cause these problems, since I can repeat these tests multiple times and get the same results. I've even resorted to padding the malloc()ed data to place the start of the volume data at a page boundary, and I still get 5.9 s rendering times.
Is there some way to instrument TLB misses? Is there something else I should instrument? If so, what and how?
Note that since the volume data is tiled, the memory access patterns are irregular.
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/
| |