Date: Sun, 7 May 1995 23:00:23 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hardware@FreeBSD.org Subject: Re: Intel 'ZAPPA' motherboard -details? Message-ID: <199505080600.XAA16028@gndrsh.aac.dev.com> In-Reply-To: <199505080457.OAA03744@godzilla.zeta.org.au> from "Bruce Evans" at May 8, 95 02:57:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> This is from a memory benchmark posted to -hackers by Bruce Evans, changed > >> by L Jonas Olsson, and then changed again by Bruce Evans to correct for > >> an extra store operation per loop. This is basically 4 x 32 bit memory > >> read or write test per iteration of the loop written in assembler. > > >Any chance that we could get this benchmark into the ports tree? > > It is a toy. I was playing with a better one that mmaps /dev/mem to avoid > cache collisions from page fragmentation, but gave up because there were > too many mmap bugs. I'm more interested in measuring the cache collisions > and avoiding them and in picking the best memory access order than in > benchmarking. I have to agree with Bruce here on this one, it is a toy, and unless you very carefull control the conditions under which you run it the results can be skewed pretty badly. I typically cold boot the machine single user and run the sequence of tests. This tends to give me a big free memory pool that has not been trashed to death by lots of vm activity. Upon Nate prodding me for a copy of the code I sent it to him and he sent me back results that are somewhat reasonable but probably not very comparitive to any results I have since his test conditions did not duplicate mine. To do this testing ideally a single user program should be written that can take over the whole machine to control the alignment of things with respect to the cache (ie, stop direct mapped cache thrashing do to logical != physical address). The other thing to be done running this as a stand alone program is to measure the different regions's of memory and how fast they are. The all important ones being L1 cache, L2 cache, main memory, and video memory. Even possible shared ISA memory on say something like a WD8013. > > Testing memory writes safely is harder. One neat method is to write a > unique pattern to pages that you own and then search for the pattern in > /dev/mem. Then it is probably safe to write to overwrite when the pattern > is in /dev/mem. This method also tells you the physical address of the > pages that you own. I'm not sure how to find the end of physical memory. > On my system, it is where accesses become very slow. Accessing nonexistent > memory may cause a panic. I think I would rather hack a kernel to bits to do the specific testing than try much harder from a user land program. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505080600.XAA16028>