Date: Mon, 3 Jan 2000 11:00:55 -0800 (PST) From: Matthew Dillon <dillon@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... Message-ID: <200001031900.LAA07286@apollo.backplane.com> References: <guido@gvr.org> <19991231010245.C630E1CA0@overcee.netplex.com.au> <20000103195100.A44079@gvr.gvr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001031900.LAA07286>
