Re: bad lmbench numbers for mmap

Larry McVoy (
Sun, 25 Apr 1999 22:18:00 -0600

: > > IIRC, Larry caught Solaris cheating and not actually mapping the
: > > pages at all until the first access.

I think that was correct - I don't remember if it was Solaris or Linux
or some other OS, but somebody was doing lazy setup and winning big.
It was not my intent to encourage lazy setup (though that may be a cool

My intent was to try and measure the cost of setting up a mapping. The
reason I wanted this number is that I wanted people to make this fast.
If it could be made essentially free, then a lot of the need for read(2)
goes away. For years and years, the crossover point where reading via
mmap was faster than reading via read(2) is around 32K. I'd like it to
be around 1K. I think Linux is pretty close.

: It' sjust that when I say "touch", I don't mean "write"..

So do you want me to change it to do reads instead?

Another thing I could do is to factor out the cost of mmap by running two

a) repeatedly read a region which is already mapped

b) repeatedly mmap & read & unmap.

In theory, b - a == mmap+munmap cost. However, if the munmap causes the
caches to get flushed, or if the new mapping is somewhere else, then cache
misses start skewing the results.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at