From owner-freebsd-hackers Tue Apr 17 6:50:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 251CA37B443 for ; Tue, 17 Apr 2001 06:50:08 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3HDnsf84122; Tue, 17 Apr 2001 09:49:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 17 Apr 2001 09:49:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kirk McKusick Cc: Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: <200104170602.XAA55944@beastie.mckusick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 16 Apr 2001, Kirk McKusick wrote: > I am still of the opinion that merging VM objects and vnodes would be a > good idea. Although it would touch a huge number of lines of code, when > the dust settled, it would simplify some nasty bits of the system. This > merger is really independent of making the number of vnodes dynamic. > Under the old name cache implementation, decreasing the number of vnodes > was slow and hard. With the current name cache implementation, > decreasing the number of vnodes would be easy. I concur that adding a > dynamically sized vnode cache would help performance on some workloads. I'm interested in this idea, although profess a gaping blind spot in expertise in the area of the VM system. However, one of the aspects of our VFS that has always concerned me is that use of a single vnode simplelock funnels most of the relevant (and performance-sensitive) calls. The result is that all accesses to an object represented by a vnode are serialized, which can represent a substantial performance hit for applications such as databases, where simultaneous write would be advantageous, or for various vn-backed oddities (possibly including vnode-backed swap?). At some point, apparently an effort was made to mark up vnode_if.src with possible alternative locking using read/write locks, but given that all the consumers use exclusive locks right now, I assume that was not followed through on. A large part of the cost is mitigated through caching on the under-side of VFS, allowing vnode operations to return rapidly, but while this catches a number of common cases (where the file is already in the cache), there are sufficient non-common cases that I would anticipate this being a problem. Are there any performance figures available that either confirm this concern, or demonstrate that in fact it is not relevant? :-) Would this concern introduce additional funneling in the VM system, or is the granularity of locks in the VM sufficiently low that it might improve performance by combining existing broad locks? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message