From dtc@scrooge.ee.swin.oz.au  Sun Oct 20 07:23:39 1996
Received: from scrooge.ee.swin.oz.au (scrooge.ee.swin.oz.au [136.186.4.20])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA21448
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 20 Oct 1996 07:23:38 -0700 (PDT)
Received: (from dtc@localhost) by scrooge.ee.swin.oz.au (8.6.9/8.6.9) id AAA16935 for FreeBSD-gnats-submit@freebsd.org; Mon, 21 Oct 1996 00:25:19 +1000
Message-Id: <199610201425.AAA16935@scrooge.ee.swin.oz.au>
Date: Mon, 21 Oct 1996 00:25:18 +1000 (EST)
From: Douglas Thomas Crosher  <dtc@scrooge.ee.swin.oz.au>
To: FreeBSD-gnats-submit@freebsd.org
Subject: madvise MADV_FREE manual page clarification

>Number:         1851
>Category:       docs
>Synopsis:       madvise MADV_FREE manual page clarification
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    mpp
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Oct 20 07:30:01 PDT 1996
>Closed-Date:    Sat Jan 25 19:35:47 PST 1997
>Last-Modified:  Sat Jan 25 19:36:52 PST 1997
>Originator:     Douglas Crosher
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
Swinburne University
>Environment:

	FreeBSD-current, Oct 18.

>Description:

From the madvise manual page:

    "MADV_FREE gives the VM system the freedom to free pages, and tells the
     system that information in the specified page range is no longer impor-
     tant.  This is an efficient way of allowing malloc(3) to free pages any-
     where in the address space, while keeping the address space valid.  The
     next time that the page is referenced, the page might be demand zeroed,
     or might contain the data that was there before the MADV_FREE call. ..."

I have a slight query on the behaviour of MADV_FREE. My initial
interpretation was that after a MADV_FREE a page would either be zero
filled or remain unchanged. However I found that pages could have
different data in them after the MADV_FREE call.

>How-To-Repeat:

I've seen this behaviour while experimenting with page freeing
strategies for a garbage collector for CMUCL.  I tried to zero fill
the pages then call madvise MADV_FREE in the hope they would be zero
the next time there were accessed, however some pages were not zero
filled.

>Fix:
	
Perhaps the documentation could be made a little clearer, I suggest:
"... The next time that the page is referenced, the page might be
demand zeroed, or might contain random data."

>Release-Note:
>Audit-Trail:

From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To: dtc@scrooge.ee.swin.oz.au (Douglas Thomas Crosher)
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/1851: madvise MADV_FREE manual page clarification
Date: Sun, 20 Oct 1996 19:29:12 +0100 (MET)

 > I have a slight query on the behaviour of MADV_FREE. My initial
 > interpretation was that after a MADV_FREE a page would either be zero
 > filled or remain unchanged. However I found that pages could have
 > different data in them after the MADV_FREE call.
 ...
 > 	
 > Perhaps the documentation could be made a little clearer, I suggest:
 > "... The next time that the page is referenced, the page might be
 > demand zeroed, or might contain random data."
 
 One thing I would like is to have a slightly different version of
 MADV_FREE which _guarantees_ the page to be zero-filled on demand. John
 Dyson said it would not hard at all (if I only knew how... :)
 
 	Luigi
 ====================================================================
 Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
 email: luigi@iet.unipi.it       Universita' di Pisa
 tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
 fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
 ====================================================================
Responsible-Changed-From-To: freebsd-bugs->mpp 
Responsible-Changed-By: mpp 
Responsible-Changed-When: Mon Dec 16 13:00:36 PST 1996 
Responsible-Changed-Why:  
Doc bug. 
State-Changed-From-To: open->closed 
State-Changed-By: mpp 
State-Changed-When: Sat Jan 25 19:35:47 PST 1997 
State-Changed-Why:  
The behaviour mentioned in the PR was due to 
a bug that should now be fixed, according to John Dyson. 
>Unformatted:
