From owner-freebsd-hackers Mon Jun 28 2: 4: 7 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 2E2C6153AE for ; Mon, 28 Jun 1999 02:04:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id CAA18676; Mon, 28 Jun 1999 02:03:41 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 02:03:41 -0700 (PDT) From: Matthew Dillon Message-Id: <199906280903.CAA18676@apollo.backplane.com> To: "Daniel J. O'Connor" Cc: Zhihui Zhang , 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 :> Otherwise they wouldn't bother to use mmap and instead would use read() :> and write() :-) : :Hmm.. why (unless you forced mmap to use the address you gave it) would it not :choose the start address to be on a page boundary? : :--- :Daniel O'Connor software and network engineer 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. Programmers who use mmap() expect it to be as close to optimal as possible. Also, even if we were to realign the data, it would not deal with the end-of-data case. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message