Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jun 1999 16:01:42 -0400 (EDT)
From:      Zhihui Zhang <zzhang@cs.binghamton.edu>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        "Daniel J. O'Connor" <darius@dons.net.au>, freebsd-hackers@FreeBSD.ORG, Ladavac Marino <mladavac@metropolitan.at>
Subject:   Re: RE: Implementation of mmap() in FreeBSD
Message-ID:  <Pine.GSO.3.96.990628155136.20491B-100000@sol.cs.binghamton.edu>
In-Reply-To: <199906281954.MAA24312@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mon, 28 Jun 1999, Matthew Dillon wrote:

> :>     it is extremely memory efficient.
> :
> :I guess you are talking about VMIO buffers where the pages are found and
> :registered into the buffer header during allocbuf().  When we do I/O on
> :VMIO buffers using conventional system call method, we specify UIO_NOCOPY
> :to instruct the uiomove() do not perform data copy. 
> 
>     UIO_NOCOPY is used to handle a degenerate case in the VFS/BIO vs VM
>     interaction for I/O, it has nothing to do with the read() or write() 
>     syscall per say, nor is it related to the mmap code.
> 
> :> Programmers who use mmap() expect it to be as close to optimal as
> :> possible. 
> :
> :I write a program to test the mmap() today. It turns out that a user can
> :modify the part of the mmapped area that is within the system returned
> :area but not part of the user-specified area. 
> :
> :As I understand it, there are two access paths to a file: conventional I/O
> :through read/write systems calls and memory-mapped I/O.  Both of them
> :converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()). 
> :This should give us the opportunity to guard against illegal memory-mapped
> :I/O writes made by the user. 
> 
>     They converge in the VMIO page cache.

By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ()
and VOP_WRITE() just as read() and write() system call.

> 
> :Maybe we can add some fields in the vm_object to record the real or
> :user-specifed area which can be passed to the vnode read and write
> :routine. In the vnode I/O routine, we should be able to limit the write to
> :only the orginal part of the area specified by the user.  This practice
> :should not incur any performance loss.
> :
> :-Zhihui
> 
>     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.

This is a good point!  I have never thought of it before.  Thanks.

-Zhihui



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?Pine.GSO.3.96.990628155136.20491B-100000>