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.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>