On Sat, 8 Apr 2000, Jason R Thorpe wrote:

> On Sat, Apr 08, 2000 at 06:13:47PM +0200, Soren S. Jorvang wrote:
> 
>  > > The numbers don't seem too bad compared with the DEC 60MHz R4400 boxes,
>  > > except the the mmap latency is ~15 times faster.  I've been seeing quite
>  > > shocking figures on both pmax and alpha - that figure is amazingly good.
>  > 
>  > I am rather suspicious of some of those mmap latency figures.
> 
> Me too.  If you look at lat_mmap.c, it doens't just mmap memory, as I
> recall.  It faults the pages in, as well.  Ah yes, just checked, it does
> fault the pages in.
> 
> So, any system that does idle-zeroing of pages on the free list is going
> to basically kick ass on that test, and any system that doesn't is going
> to incur the penalty of ZFOD when those pages are touched.
> 
> So, it is in fact not an "mmap latency" test but rather an "mmap + ZFOD
> latency" test.  And, more than that, it's also testing the latency of
> setting setting up page table mappings for systems that do that lazily.
> 
> And even if the test is labeled correctly, it's not precisely fair.  A
> system with a virtually tagged cache would be foolish to pre-zero pages
> in the idle loop; that cache load would be wasted, and could potentially
> throw other useful data out of the cache (unless the access was done
> un-cached).
> 
> Basically, the test is skewed very much in favor of Linux/i386.  The i386's
> cache is physically tagged (so it is at least not *wasting* the cache load),
> and Linux's VM system sets up all of the page tables when the mmap system
> call occurs.

	Maybe someone could some up with another test that is fair for
	machines with virtually tagged cache, and see if they can get it
	into lmbench? - or if not leave it in a patch in pkgsrc :)

		David/absolute