From owner-freebsd-hackers Tue Apr 17 10:12:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7126737B424; Tue, 17 Apr 2001 10:12:19 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHCIG93862; Tue, 17 Apr 2001 10:12:18 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:12:18 -0700 (PDT) From: Matt Dillon Message-Id: <200104171712.f3HHCIG93862@earth.backplane.com> To: Robert Watson Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, David Xu Subject: Re: vm balance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 :... We only use simplelocks on vnodes for interlock operations. We use normal kern/kern_lock.c locks for vnode locking and use both shared and exclusive locks. You are absolutely correct about the serialization that can occur. A stalled write() will stall all other write()'s plus any read()'s. Stalled write()s are easy to come by. I did some work in this area to try to mitigate the problem. In 4.1/4.2 I added the bwillwrite() function. This function is called prior to obtaining the exclusive vnode lock and blocks the process if there aren't a sufficient number of filesystem buffers available to (likely) accomodate the operation. This (mostly) prevents the process from blocking in the buffer cache while holding an exclusive vnode lock and makes a big difference. :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 The VM system is in pretty good shape in regards to fine-grained locking (you get down to the VM page). The VFS system is in terrible shape - there is no fine grained locking at all for writes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message