Date: Tue, 17 Apr 2001 09:49:54 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Kirk McKusick <mckusick@mckusick.com> Cc: Julian Elischer <julian@elischer.org>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com>, David Xu <bsddiy@21cn.com> Subject: Re: vm balance Message-ID: <Pine.NEB.3.96L.1010417093922.83886C-100000@fledge.watson.org> In-Reply-To: <200104170602.XAA55944@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010417093922.83886C-100000>