From owner-freebsd-current Fri Apr 14 20:39:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA25082 for current-outgoing; Fri, 14 Apr 1995 20:39:25 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA25072 for ; Fri, 14 Apr 1995 20:39:21 -0700 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id UAA18656; Fri, 14 Apr 1995 20:39:02 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id UAA00248; Fri, 14 Apr 1995 20:39:01 -0700 Message-Id: <199504150339.UAA00248@corbin.Root.COM> To: Bruce Evans cc: jgreco@brasil.moneng.mei.com, freebsd-current@FreeBSD.org, hsu@cs.hut.fi Subject: Re: mmap bugs gone yet? In-reply-to: Your message of "Sat, 15 Apr 95 13:02:54 +1000." <199504150302.NAA01886@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 14 Apr 1995 20:38:52 -0700 Sender: current-owner@FreeBSD.org Precedence: bulk >> mmap should be faster at accessing files randomly and will eliminate an >>extra copy compared with doing read() system calls. It might be slower when >>modifying large amounts of large files. I think overall mmap would be faster, >>but YYMV. > >Does mmap() do read-ahead or read-behind? If it does, then it wouldn't be >so good for random access. If it doesn't then it wouldn't be so good for It does. >seuqential access. What exactly happens if a huge file (larger than >physical memory) is accessed sequentially using read() and mmap()? E.g., >for simple (simplistic?) copying of files: > > read-write: > size = huge; buf = malloc(size); read(0, buf, size); write(1, buf, size); > mmap: > something I can't write without RTFM :-) It works, but modifying large parts of large files is slow (as I already said above). This is mostly because doing the I/O through the vnode pager interface (and then back through the VFS buffer code) is higher overhead than just doing a write(). If the pagedaemon gets involved, this will slow things further (there are two ways that the pages will be cleaned - either by the pagedaemon or via 'sync' [the update daemon]. 'sync' is faster.). -DG