From owner-freebsd-hackers Mon Apr 16 5:23:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id EE83F37B43C for ; Mon, 16 Apr 2001 05:23:38 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f3GCNZZ51680 ; Mon, 16 Apr 2001 21:23:36 +0900 (JST) Message-Id: <200104161223.f3GCNZZ51680@rina.r.dl.itc.u-tokyo.ac.jp> Date: Mon, 16 Apr 2001 21:23:34 +0900 From: Seigo Tanimura To: phk@critter.freebsd.dk Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, bright@wintelcom.net, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: In your message of "Mon, 16 Apr 2001 12:36:03 +0200" <1198.987417363@critter> References: <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp> <1198.987417363@critter> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Apr 2001 12:36:03 +0200, Poul-Henning Kamp said: Poul-Henning> In message <200104161024.f3GAO7Z34787@rina.r.dl.itc.u-tokyo.ac.jp>, Seigo Tanim Poul-Henning> ura writes: >> Those pieces of work were done in the last weekend, and the patch at >> Seigo> http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff >> >> has been updated and now ready to commit. Poul-Henning> I'm a bit worried about the amount of work done in the Poul-Henning> cache_purgeleafdirs(), considering how often it is called, Poul-Henning> Do you have measured the performance impact of this to be an Poul-Henning> insignificant overhead ? No precise results right now, mainly because I cannot find a benchmark to measure the performance of name lookup going down to a deep directory depth. It has been confirmed, though, that the hit ratio of name lookup is around 96-98% for a box serving cvsup both with and without my patch (observed by systat(1)). Here are the details of the name lookup on that box: Frequency: Around 25,000-35,000 lookups/sec at most, 8,000-10,000 generally. Name vs Directory: 98% or more of the lookups are for names, the rest of them are for directories (up to 1.5% of the whole lookup at most). Hit ratio: 96-98% for names and up to 1% at most for directories (both with and without my patch) Considering that most of lookup operations are for names and its hit ratio is not observed to degrade, and assuming that the time consumed for lookup hit is always constant, the performance of lookup is not found to be deteriorated. For a more precise investigation, we have to measure the actial time taken for a lookup operation, in which case I may have to write a benchmark for it and test in single-user mode. It is interesting that the hit ratio of directory lookup is up to only 1% at most, even without my patch. Why is it like that? -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message