Date: Thu, 16 May 1996 09:33:15 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: dyson@freebsd.org, hackers@freebsd.org Subject: Re: EDO & Memory latency Message-ID: <199605161433.JAA13613@dyson.iquest.net> In-Reply-To: <199605160907.PAA10321@hq.icb.chel.su> from "Serge A. Babkin" at May 16, 96 03:07:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > You likely are seeing TLB overhead intrinsic to the processor. Some processors > > don't have microcode TLB management, and you'll see worse numbers, because the > > TLB needs to be handled in normal machine/assembly code. (Of course, on those > > processors, you can tune the TLB management more freely.) > > But I tried to run it on Pentium that has microcode implementation of TLB. > What I was implying above was that R4400 (approx the same speed in general as a fast pentium) was taking 2usecs, while the Pentium takes 400usecs (on my machine). Paging isn't the issue, it is TLB updates and propagation through the glue and cache to main memory. R4400's don't handle the TLB in microcode, and the Pentium does. This is one of the *big* suprises that people sometimes find out -- those TLB updates do make a difference. I had a customer whose application was running several times slower on a R4400 box than expected. It was due to clashing with the TLB update policy. We reorganized the code, and the performance went up higher than expectations!!! If you caused your system to page, that is because there were other pages in the system that the VM system deemed to be higher priority, or you were simply out of memory. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605161433.JAA13613>