Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Jul 1998 22:16:21 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        green@zone.baldcom.net (Brian Feldman)
Cc:        andre@pipeline.ch, karl@mcs.net, current@FreeBSD.ORG
Subject:   Re: MMAP problems
Message-ID:  <199807262216.PAA18637@usr01.primenet.com>
In-Reply-To: <Pine.BSF.4.00.9807251817390.6651-100000@zone.baldcom.net> from "Brian Feldman" at Jul 25, 98 06:20:19 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Hmm, what is the default behavior of msync()? Is it handled automatically,
> say, in-kernel? If so, maybe it needs to be explicitly called; also is
> this daemon using a drive with async/softupdates by any chance?

It is supposed to be automatic in the case of a unified VM and buffer
cache, by definition.

The one place that this is not true is non-fault based file extension,
ie: when you extend a file within the last page of the file, while the
file is memory mapped.

Probably the correct thing to do in this case is to think of backing
objects in terms of pages instead of thinking of them in terms of
variable length anonymous memory.

This would mean that you would grab a full page *and note that you
had done so* to back frags in an mmap'ed region.

Then if an extension occurs, the changes are made to the page as a
page instead of as a frag, and coherency is maintained.

The final issue is that when you write fault in the partial page,
you look at the backing object to determine the length so that
you don't fault zero-filled partial objects out, ending up with
your last 0-7 physical blocks getting zeroed.


This is more an issue of whether or not the additional overhead is
worth avoiding the msync() or not...

It is interesting to note that incoherent VM systems (ie: non-unified
VM and buffer cache 8-)) do not have this problem.  By definition,
they will copy only the data from the region into the buffer cache
from teh VM.  This will result in "correct" (user expected) behaviour
on file extension, without needing msync().


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807262216.PAA18637>