From owner-freebsd-hackers Mon Jun 28 12:47: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sol (cs1-gw.cs.binghamton.edu [128.226.171.72]) by hub.freebsd.org (Postfix) with SMTP id 62BAE14FCB for ; Mon, 28 Jun 1999 12:46:39 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from localhost (zzhang@localhost) by sol (SMI-8.6/8.6.9) with SMTP id PAA20468; Mon, 28 Jun 1999 15:34:15 -0400 Date: Mon, 28 Jun 1999 15:34:15 -0400 (EDT) From: Zhihui Zhang Reply-To: Zhihui Zhang To: Matthew Dillon Cc: "Daniel J. O'Connor" , freebsd-hackers@FreeBSD.ORG, Ladavac Marino Subject: Re: RE: Implementation of mmap() in FreeBSD In-Reply-To: <199906280903.CAA18676@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Because we can't realign the data in the pages without doing a buffer > copy. To force mmap() to align the data to the start of the page requires > it to allocate memory and copy the in-core disk cache to the new memory. > > This is extremely wasteful of cpu and memory. The current UNIX mmap > implementation is able to simply map the existing in-core disk cache > directly to the process - no buffer copying is required at all, and > 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. > 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. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message