Date: Tue, 17 Apr 2001 22:40:21 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Robert Watson <rwatson@FreeBSD.ORG> 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: <200104180540.WAA58303@beastie.mckusick.com> In-Reply-To: Your message of "Tue, 17 Apr 2001 09:49:54 EDT." <Pine.NEB.3.96L.1010417093922.83886C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
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
Every vnode in the system has an associated object. Every object
backed by a file (e.g., everything but anonymous objects) has an
associated vnode. So, the performance of one is pretty tied to the
performance of the other. Matt is right that the VM does locking
on a page level, but then has to get a lock on the associated
vnode to do a read or a write, so really is pretty tied to the
vnode lock performance. Merging the two data structures is not
likely to change the performance characteristics of the system for
either better or worse. But it will save a lot of headaches having
to do with lock ordering that we have to deal with at the moment.
Kirk McKusick
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?200104180540.WAA58303>