From owner-freebsd-current  Mon Jan 20 04:26:54 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA27250
          for current-outgoing; Mon, 20 Jan 1997 04:26:54 -0800 (PST)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id EAA27234
          for <current@freebsd.org>; Mon, 20 Jan 1997 04:26:42 -0800 (PST)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA13956; Mon, 20 Jan 1997 12:42:39 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199701201142.MAA13956@labinfo.iet.unipi.it>
Subject: Re: possible madvise MADV_FREE improvement
To: dtc@scrooge.ee.swin.oz.au (Douglas Thomas Crosher)
Date: Mon, 20 Jan 1997 12:42:39 +0100 (MET)
Cc: current@freebsd.org
In-Reply-To: <199701201158.WAA19937@scrooge.ee.swin.oz.au> from "Douglas Thomas Crosher" at Jan 20, 97 10:57:47 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > when does the system decide for disposing the pages, and wouldn't it be
> > nice (and easy to implement) to have an option to force this behaviour ?
...
> With the recent improvements it's not too much more costly to have the
> application zero the page, then call madvise MADV_FREE. But be careful

ouch! my point was to avoid an explicit zeroing of the page(s) to
possibly reduce the latency of a bzero()/calloc() in case zeroed
pages already exist, and to reduce the memory footprint in case a
huge chunk of memory is used to simulate an associative array (I
do this from time to time, when you know you have enough RAM your
code runs very fast and you save a lot of coding time!)

	Luigi