Date: Fri, 14 Apr 1995 20:38:52 -0700 From: David Greenman <davidg@Root.COM> To: Bruce Evans <bde@zeta.org.au> Cc: jgreco@brasil.moneng.mei.com, freebsd-current@FreeBSD.org, hsu@cs.hut.fi Subject: Re: mmap bugs gone yet? Message-ID: <199504150339.UAA00248@corbin.Root.COM> In-Reply-To: Your message of "Sat, 15 Apr 95 13:02:54 %2B1000." <199504150302.NAA01886@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504150339.UAA00248>