On Tue, Mar 19, 2002 at 08:11:54PM +0000, Brian J. Beesley wrote: > Ah, but ... frequently accessing pages (virtual _or_ physical) will > keep the TLB pages from getting too far away from the processor; > probably at worst they will stay in the L1 cache.
Yes. > The overhead of accessing from L1 cache is small compared with the > overhead of accessing data from main memory, and _tiny_ compared > with the overhead of accessing data from the page/swap file. Yes... but a TLB miss costs one or maybe two extra memory cycles. Ie it halves the performance if you are missing every fetch. > Don't you _need_ to have at least enough TLB entries to map the > whole of the processor cache? (Since without it you can't map the > cache table entries...) Hmm, not sure. The processor cache isn't directly mapped into memory so it doesn't need TLB entries. Depending on the architecture the cache will either cache physical addresses or logical addresses. [snip] > Whatever effect TLB thrashing may or may not be having, it doesn't look as > though it's having a dominant effect on mprime. Very true and that is a testament to George's programming skills. A naively programmed FFT will demonstrate TLB thrashing admirably! > > I think this would make a real difference to mprime - what percentage > > I don't know - at the cost of on average 1 MB of RAM extra. > > I wouldn't mind _doubling_ the memory footprint, if we got a _significant _ > performance boost as a consequence. Me neither. I'd like to try it but I need to persuade some friendly kernel hacker to implement it for me ;-) I would guess it might make at most 10% difference to the run time. > BTW why does this argument apply only to mprime? Surely Windows has the same > underlying architecture - though obviously it's harder to get the Windows > kernel changed than linux. It applies exactly the same to Windows of course. Its just that you can chat with the Linux kernel developers on the mailing list ;-) -- Nick Craig-Wood [EMAIL PROTECTED] _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
