From owner-freebsd-emulation  Mon Jan  3 11: 1:19 2000
Delivered-To: freebsd-emulation@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id A0A181541A; Mon,  3 Jan 2000 11:01:09 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id LAA07286;
	Mon, 3 Jan 2000 11:00:55 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 3 Jan 2000 11:00:55 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200001031900.LAA07286@apollo.backplane.com>
To: Guido van Rooij <guido@gvr.org>
Cc: Peter Wemm <peter@netplex.com.au>,
	Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>,
	vsilyaev@mindspring.com, dillon@FreeBSD.ORG,
	freebsd-emulation@FreeBSD.ORG, dbutter@wireless.net
Subject: Re: VMware: Questions...
References: <guido@gvr.org> <19991231010245.C630E1CA0@overcee.netplex.com.au> <20000103195100.A44079@gvr.gvr.org>
Sender: owner-freebsd-emulation@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


:
:I am now using the following patch. I had a printf in the if clause
:to see if other processes would use the code, but vmware seems the only one.
:
:In fact I have been thinking about an fcntl() for files to b able
:to specify the nosync option. This would be handy in mkstemp().
:However Bruceb thinks it would not result in much improvement.
:
:-Guido
:
:--- vm_mmap.c.orig	Sun Dec 12 04:19:29 1999
:+++ vm_mmap.c	Fri Dec 24 10:08:37 1999
:@@ -1024,6 +1024,14 @@
: 				return (error);
: 			objsize = round_page(vat.va_size);
: 			type = OBJT_VNODE;
:+			/*
:+			 * if it is a regular file without any references
:+			 * we do not need to sync it.
:+			 */
:+			if (vp->v_type == VREG && vat.va_nlink == 0) {
:+				flags |= MAP_NOSYNC;
:+			}
: 		}
: 	}

    Simple and to the point.  The patch looks fine, I would go ahead and
    commit it!  

    re: NOSYNC on write() for tmp files via fctl - no, there wouldn't be much
    of an improvement.  Softupdates takes care of it pretty well and if you
    aren't running softupdates on the partition you still have the
    create/delete overhead to contend with which in most cases will be
    worse then for write() due to being semi-synchronous (without softupdates)
    rather then asynchronous (with softupdates).

    Also, it's possible to 'over-use' the feature and force the machine into
    doing unnecessary paging.  I did a big set of experiments while working on
    the write clustering code and found that attempting to leave filesystem
    writes entirely up to the VM system resulted in fairly bad performance.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message