From owner-freebsd-hackers Mon Jun 28 12:54:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BB19D15028 for ; Mon, 28 Jun 1999 12:54:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA24312; Mon, 28 Jun 1999 12:54:12 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 12:54:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199906281954.MAA24312@apollo.backplane.com> To: Zhihui Zhang Cc: "Daniel J. O'Connor" , freebsd-hackers@FreeBSD.ORG, Ladavac Marino Subject: Re: RE: Implementation of mmap() in FreeBSD References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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. :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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message