Date: Mon, 28 Jun 1999 14:07:20 -0700 From: Jason Thorpe <thorpej@nas.nasa.gov> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Zhihui Zhang <zzhang@cs.binghamton.edu>, "Daniel J. O'Connor" <darius@dons.net.au>, freebsd-hackers@FreeBSD.ORG, Ladavac Marino <mladavac@metropolitan.at> Subject: Re: Implementation of mmap() in FreeBSD Message-ID: <199906282107.OAA22292@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT)
Matthew Dillon <dillon@apollo.backplane.com> wrote:
> mmap bypasses the vnode. What you propose will not work because even if
> the VM object is process-specific, the pages underlying the VM object are
> not. If several processes are mmap()ing overlapping portions of the file,
> they are *sharing* the pages. So even though they are not sharing the
> VM object, the VM system will not be able to tell which process modified
> the page, and therefore any byte-ranged limits specified in the VM object
> will be useless.
Well, if you make a VM object map-entry-specific (not just "process-specific";
a single process may have multiple mappings of a file!), then the pages
*can't* be shared, because pages are owned by the objects. The only reason
you can share pages is because multiple map entries may reference the same
object (the offset into the object being map-entry-specific).
Put another way, it's not possible for this sentence to be true, at all:
What you propose will not work because even if the VM object is
process-specific, the pages underlying the VM object are not.
...since the presence of map-entry-specific objects would make the pages
also map-entry-specific by definition.
This, of course, would mean that VM objects themselves serve no purpose, so
you could collapse it into "pages are owned by VM map entries", and do away
with objects completely.
However, that would be stupid.
Anyhow, it's possible to have the semantics Zhihui suggested, but you have to
give up an awful lot to get them. :-)
-- Jason R. Thorpe <thorpej@nas.nasa.gov>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906282107.OAA22292>