Date: Thu, 16 May 1996 01:13:11 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: babkin@hq.icb.chel.su (Serge A. Babkin) Cc: hackers@freebsd.org Subject: Re: EDO & Memory latency Message-ID: <199605160613.BAA07537@dyson.iquest.net> In-Reply-To: <199605160309.JAA29241@hq.icb.chel.su> from "Serge A. Babkin" at May 16, 96 09:09:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have just tried lmbench and the numbers it gives are looking > slightly strange for me. It shows memory latency upto 500ns while > I have 60-ns EDO memory in a Pentium/75 box. Okay, its external > clock is 25MHz, this gives 40ns, one wait state, it gives another 40ns, > it gives 80ns, but why the overhead is over 400ns ? > > Can it go from some VM subsystem activity ? I have 16M of RAM in my box > and I runned lmbench with 8M maximal buffer size. The latency grows > with the size of buffer. Is it possible that when > the size of buffer grows the VM subsystem moves the non-recently used > pages to some pool and when they are accessed again it gets the VM fault > and remaps them back to that process? > There are several things going on. One is that there is propagation time through to the main memory, it is much worse than the memory cycle time. Of course, that does not account for all of the 400 nsecs that you are seeing. BTW, the R4400 boxes that I used to work on reported about 2usecs for large strides!!!! R3000's actually overflowed the counter :-). 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.) John dyson@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605160613.BAA07537>