Re: rbtree for vm_map
Noriyuki Soda <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.performance |
|---|---|
| Message-ID | <[email protected]> |
>>>>> On Fri, 31 Oct 2003 10:10:34 +0000, Chris Gilbert <[email protected]> said: >> I measured the mmap benchmarks in http://bulk.fefe.de/scalability/ >> with the vm map rbtree patch ported from OpenBSD by yamt. : >> mmap()ing many small files: >> http://www.sra.co.jp/people/soda/scalability/open.gif > Have you had a chance to look into why the open results? It looks quite > bad, Perhaps you are misunderstanding that the rbtree patch makes the result bad? Acutally, the rbtree patch makes the result much better. The open.gif graph is drawn by the following order: Linux-2.6.6-test8, NetBSD-splay, NetBSD-splay+rbtree The following one is the graph which is drawn by opposite order: http://www.sra.co.jp/people/soda/scalability/open.2.gif In other words, The reason why the NetBSD-splay+rbtree looks bad is because it's drawn over the NetBSD-splay graph. And as you see, the rbtree patch makes non-spike case much better. Average height of the spike cases is followings: NetBSD-splay: 3.4ms NetBSD-splay+rbtree: 3.0ms > or are the very frequent spikes just single values? > Would the fdalloc help here? The spikes happen exactly once per 100 openings on NetBSD with or without the rbtree patch. Because the average height of the spike is 3 microseconds, I guess NetBSD actually accesses harddisk to read metadata in the spike cases. I don't know why Linux doesn't show the frequent spikes. Perhaps because of larger namei cache? -- soda