lkml.org 
[lkml]   [1998]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TLB refill problems again?
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/

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