From owner-freebsd-hackers  Tue Dec 10 13:09:23 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id NAA00919
          for hackers-outgoing; Tue, 10 Dec 1996 13:09:23 -0800 (PST)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA00914
          for <hackers@freebsd.org>; Tue, 10 Dec 1996 13:09:20 -0800 (PST)
Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id QAA00660; Tue, 10 Dec 1996 16:09:06 -0500 (EST)
From: John Dyson <dyson@dyson.iquest.net>
Message-Id: <199612102109.QAA00660@dyson.iquest.net>
Subject: Re: Multiple Buffer allocation of Shared Memory
To: erich@lodgenet.com (Eric L. Hernes)
Date: Tue, 10 Dec 1996 16:09:06 -0500 (EST)
Cc: kelly@fsl.noaa.gov, erich@lodgenet.com, scrappy@hub.org,
        hackers@freebsd.org
In-Reply-To: <199612102020.OAA17243@jake.lodgenet.com> from "Eric L. Hernes" at Dec 10, 96 02:20:37 pm
Reply-To: dyson@freebsd.org
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> correct me if I'm wrong here, but doesn't MFS allocate backing store
> in swap, so it could be paged out via physical I/O too.  In either case
> the physical IO appears async -- the physio won't happen until
> the system needs ram, or the pages are inactive.  If you've got enough
> ram, the mmap'ed file won't be flushed out no matter what the underlying
> FS is.  Or do I just have too much faith in the VM system? ;-)
> 
It is flushed on msync paged out when memory gets scarce.  I think that
the update process also syncs the mmaped regions (with vnode backing.)

John