From owner-freebsd-hackers  Tue May  1 10:20:57 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP
	id 47CBE37B639; Tue,  1 May 2001 10:20:47 -0700 (PDT)
	(envelope-from dillon@earth.backplane.com)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.2/8.11.2) id f41HKb268250;
	Tue, 1 May 2001 10:20:37 -0700 (PDT)
	(envelope-from dillon)
Date: Tue, 1 May 2001 10:20:37 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200105011720.f41HKb268250@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
References: <200104180540.WAA58303@beastie.mckusick.com> <3AEE713D.C0A35C82@mindspring.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


: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