Messages in this thread |  | | | From | (Linus Torvalds) | | Subject | Re: bad lmbench numbers for mmap | | Date | 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/
|  |