On Thursday 05 April 2001 08:25 am, Jeff Epler wrote:
>
> It's likely due to Linux' lack of page coloring.
>
> Let's see if I can get the explanation right ... The L2 cache is typically
> physically mapped, and so for some value N the addresses A and A+N alias
> to the same cache line. N is some multiple of the page size--- For the
> Pentium III, with 256K 4-way cache (according to sandpile.org), N is
> 64k.
>
> Now, imagine that your application uses 8 pages of code+data. If they
> are allocated to be physically contiguous (rather than just virtually
> contiguous), they will all be able to fit in cache simultaneously,
> because none of the cache lines aliases any of the other cache lines.
> This is the best case. Once all the cache lines are loaded, you'd never
> have an (L2) cache miss.
>
> But if each page is mapped 64k apart physically, any given address in
> the page aliases to the same cache line. The cache has 4 ways, so at
> most half of your (code+data) can reside in the L2 cache at one time. A
> truly pessimal program might need to do a load from main memory at each
> memory reference.
>
> My theory, then, is that depending where between these two extremes the
> page allocation lies, you'll get a different 'top FPS' and 'average FPS'
> within some range of variability.
>
> Jeff
Ah yes! I totally forgot about cache contention. This would definitely
explain it.
--
Nobody will ever need more than 640 kB RAM.
-- Bill Gates, 1983
Windows 98 requires 16 MB RAM.
-- Bill Gates, 1999
Nobody will ever need Windows 98.
-- logical conclusion
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
