Skip site navigation (1)Skip section navigation (2)
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>