>>>>> On Fri, 31 Oct 2003 10:10:34 +0000,
	Chris Gilbert <chris@dokein.co.uk> 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