From owner-freebsd-hackers  Thu May 18 11:39:15 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id LAA15415
          for hackers-outgoing; Thu, 18 May 1995 11:39:15 -0700
Received: from uuneo.neosoft.com (root@uuneo.NeoSoft.COM [198.64.84.252])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA15409
          for <hackers@freebsd.org>; Thu, 18 May 1995 11:39:14 -0700
Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.6.10/8.6.10) with UUCP id NAA21377 for freebsd.org!hackers; Thu, 18 May 1995 13:05:42 -0500
Received: by ris1.nmti.com (smail2.5)
	id AA09446; 18 May 95 12:39:04 CDT (Thu)
Received: by sonic.nmti.com; id AA03902; Thu, 18 May 1995 13:00:24 -0500
Date: Thu, 18 May 1995 13:00:24 -0500
From: peter@nmti.com (Peter da Silva)
Message-Id: <9505181800.AA03902@sonic.nmti.com.nmti.com>
To: jkh@FreeBSD.org
Subject: Ron Minnich in comp.os.research: Status of Linux/FreeBSD/NetBSD buffer/vm page integration
Cc: hackers@FreeBSD.org
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>From comp.os.research:

Path: nmtigw!uuneo.neosoft.com!news.uh.edu!swrinde!howland.reston.ans.net!spool.mu.edu!agate!darkstar.UCSC.EDU!osr
From: rminnich@tres.sarnoff.com (Ron Minnich)
Newsgroups: comp.os.research
Subject: Status of Linux/FreeBSD/NetBSD buffer/vm page integration
Date: 16 May 1995 20:32:55 GMT
Organization: SRI International
Lines: 44
Approved: comp-os-research@ftp.cse.ucsc.edu
Message-ID: <3pb25n$mv4@darkstar.UCSC.EDU>
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@cse.ucsc.edu

Suppose you do the following:

int fd;
int *ptr;
fd = open("something", 2);
ptr = mmap(0, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

*ptr = 1;

Then you do either:
msync(ptr, sizeof(*ptr), MS_INVALIDATE)	-or-	fsync(fd);

On SunOS and many systems, you will see the same result when watching
over the net: an nfs write at the point of the msync OR the fsync, for
the "dirty" pages only. It's pretty much what you want: sync the
modified pieces of the file back to their home.

On FreeBSD, you don't get the same things at all: fsync and msync are
very different in freebsd. They are concerned with totally different
pieces of the kernel and if you depend on the "right thing" happening
you're in for a surprise.  Specifically, if you use an fsync in the
above sequence there can still be (lots) of dirty pages for that file
in you machine, if they apply to mmap'ed files.

Anyone want to comment on the state of linux and netbsd? Last time I
checked they did not have it right either. Not surprising for netbsd
since it's basically the same structure (same mach vm code, ow). On
linux, you still couldn't mmap a file with PROT_WRITE as of several
months ago -- it loses instantly. How about systems such as chorus,
windows/nt, etc? It's interesting that this simple sequence has worked
right on (e.g.) SunOS for so long (almost 7 years ...), and we're still
not there on so many other systems.

thanks
ron


--
Ron Minnich                |Constant performance conjecture: programs written
rminnich@earth.sarnoff.com |using object-oriented techniques will exhibit 
(609)-734-3120             |constant performance, even as CPU speeds double.
		   | See: Microsoft word 6.x