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