lkml.org 
[lkml]   [1999]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.071 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site