Re: bad lmbench numbers for mmap

Linus Torvalds (torvalds@transmeta.com)
17 Apr 1999 05:54:40 GMT


In article <199904170139.HAA15287@vxindia.vxindia.veritas.com>,
V Ganesh <ganesh@vxindia.veritas.com> wrote:
>
>not very likely. if you are writing out a swap page, filemap_write_page
>queues the request to kpiod, which seems to be the only new feature in there.
>otherwise it just winds up calling ext2_file_write which doesn't normally
>wait for all pages to hit disk.

Regardless, I only now realized that "lat_mmap" is not actually testing
the latency of a normal mapping and population of that mapping: it's
testing the latency of creating a file by _writing_ to it through a
mmap.

Interesting. I hadn't realized at all: it originally used to just map
in the file - without actually ever touching it. Linux got extremely
good numbers, because Linux did it all lazily and never actually created
the page tables.

I actually complained about that to Larry, because despite the fact that
we did well I didn't think it was a very realistic or useful benchmark:
mapping something without ever toucing the pages you map is not usually
considered very useful. But I only now realized that not only does the
thing touch the pages, it actually _dirties_ them too.

Larry, why did you do the page dirtying thing? That's not a very common
thing for people to do, and it makes the benchmark pretty misnamed (I
hadn't even looked at the sources very closely before this thread came
up).. It's much more common to mmap for reading than for writing
(executables etc), and maybe you should split the cases (and make
reading the common case).

Anyway, I'll see if I can come up with something obvious for making the
writing faster.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/