From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 17 12:38:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9262016A4D3 for ; Wed, 17 Dec 2003 12:38:28 -0800 (PST) Received: from f7.mail.ru (f7.mail.ru [194.67.57.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9811143D31 for ; Wed, 17 Dec 2003 12:38:23 -0800 (PST) (envelope-from shmukler@mail.ru) Received: from mail by f7.mail.ru with local id 1AWiR4-000FNQ-00 for freebsd-hackers@freebsd.org; Wed, 17 Dec 2003 23:38:22 +0300 Received: from [24.184.137.78] by msg.mail.ru with HTTP; Wed, 17 Dec 2003 23:38:22 +0300 From: =?koi8-r?Q?=22?=Igor Shmukler=?koi8-r?Q?=22=20?= To: freebsd-hackers@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.184.137.78] Date: Wed, 17 Dec 2003 23:38:22 +0300 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: Subject: a possible explanation for the mmap benchmarks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?koi8-r?Q?=22?=Igor Shmukler=?koi8-r?Q?=22=20?= List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2003 20:38:28 -0000 First of all I do not want to start any kind of war here. I studied results of Felix's benchmark some time ago and now I think I have a possible explanation for what happens. I do not mean to invalidate results. I just want to offer a cause, in case someone is unaware. What does mmapbench do? It does mmap of every other page on 200MB file (by default). Since it does mmap sequentialy, free space linear search vs hint works very well, so we get almost constant time free space allocation (I have tested Linux kernel 2.4 - it spends more and more time on each subsequent mmap as the number of mapped regions growth. 2.6 should be OK, since they are start using search hint :-) ) During sequential mmaping, splay tree [used in vm_map_lookup_entry()] degenerates to a list. Later, when mmapbench sequentialy touches mmaped regions, entry search using degenerated splay tree gives almost the same results as linear entry search vs hint. So again - no improvements on such test conditions. RB-tree (NetBSD), as I understand, rebalances itself after each insert. Splay tree only does rebalancing during sort. The questions is whether altered benchmark, where things are done randomly will produce similar results. I do not know the answer, yet. However, I believe it very well might. I would be glad to know whether it seems reasonable to anyone? I contacted the author, but he has not had a chance to reply yet.