Date: Tue, 1 May 2001 10:20:37 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kirk McKusick <mckusick@mckusick.com>, Robert Watson <rwatson@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, David Xu <bsddiy@21cn.com> Subject: Re: vm balance Message-ID: <200105011720.f41HKb268250@earth.backplane.com> References: <200104180540.WAA58303@beastie.mckusick.com> <3AEE713D.C0A35C82@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I think we need to remember that we do not always have a
:backing object, nor is a backing object always desirable.
:
:The performance of an mmap'ed file, or swap-backed anonymous
:region is _significantly_ below that of unbacked objects.
:
:-- Terry
This is not true, Terry. There is no performance degredation with
swap verses unbacked storage, and no performance degredation with
file-backed storage if you use MAP_NOSYNC to adjust the write flushing
characteristics of the map. Additionally, there is no 'write through'
in the VM layer per-say -- the filesystem syncer has to come along
and actually look for dirty pages to sync to the backing store (and
with MAP_NOSYNC it doesn't bother). The VM layers do not touch the
backing store at all until they absolutely have to. For example, swap
is not allocated until the pagedaemon actually decides to page something
out.
This leaves only the pageout daemon which operates as it always has...
if you are not squeezed for memory, it won't try to page anything out.
And you can always use madvise(), msync(), and mlock() on top of
everything else to adjust the VM characteristics of a section of
memory (though personally speaking I don't think mlock() is necessary
with 4.x's VM system unless you need realtime).
In short, mmap()'s backing store is not an issue in 4.x. Read the
manual page for mmap for more information, I fleshed it out a long time
ago to explain all of this.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105011720.f41HKb268250>