From owner-freebsd-current  Tue Oct 29 10:22:58 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA14811
          for current-outgoing; Tue, 29 Oct 1996 10:22:58 -0800 (PST)
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 KAA14806;
          Tue, 29 Oct 1996 10:22:55 -0800 (PST)
Received: (from dtc@localhost) by scrooge.ee.swin.oz.au (8.6.9/8.6.9) id FAA03537; Wed, 30 Oct 1996 05:24:40 +1100
From: Douglas Thomas Crosher  <dtc@scrooge.ee.swin.oz.au>
Message-Id: <199610291824.FAA03537@scrooge.ee.swin.oz.au>
Subject: Re: Request to add this to FAQ re: swap space
To: dyson@freebsd.org
Date: Wed, 30 Oct 1996 05:24:39 +1100 (EST)
Cc: current@freebsd.org
In-Reply-To: <199610290207.VAA04150@dyson.iquest.net> from "John S. Dyson" at Oct 28, 96 09:07:20 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > ... The algorithm that is used by FreeBSD also requires that every
> > anonymous page in a process be backed by at least an equivalent amount
> > of swap space, and perhaps significantly more. ...
> > 
> Unfortunately there are at least three wild-cards:  the entire virtual
> space is not shown by ps (there is a new mechanism, but would require a shell
> script reading /proc/???/map), there are issues regarding the
> inheritance of pages through fork, and sometimes the space is rounded
> up by the swap pager.  Each of those can make it so that FreeBSD uses
> more space than the total virtual size.  However, 2X should be too much
> but allows for significant safety factor.
> 
> If you ever have a situation where FreeBSD uses more space than approx
> 1X the total size of all running processes, please get in touch with me.
> At least we can get to the bottom of it.

Below is a program which seems to demonstrate the effect I'm
seeing. Although there is never more than 64M allocated, the swap
usage due to the process seems to settle at about 80M. (The test
machine had 64M ram, and 192M swap; the residual swap usage before and
after the process was about 6M, growing to about 89M while running.)

The only way I've found of avoiding this is to allocate the initial
region a page at a time. However doing so seems to reduce performance,
so I figured there was a tradeoff somewhere and happily use a little
more swap.

Regards
Douglas Crosher

-=-=-=-=-

#include <stdio.h>
#include <sys/types.h>
#include <sys/mman.h>
#define NUM_PAGES 16384
main() {
  mmap(0x9000000,NUM_PAGES*4096, PROT_READ|PROT_WRITE|PROT_EXEC,
       MAP_PRIVATE|MAP_ANON,-1,0);
  for (;;) {
    int page;
    for (page=0;page<NUM_PAGES;page++) {
      int  *addr = (int *)((void *)0x9000000 + 4096*page);
      *addr = *addr; }
    for (page=0;page<NUM_PAGES;page++) {
      int  *addr = (int *)((void *)0x9000000 + 4096*page);
      if (random()%10 == 0) {
	munmap((void *)addr,4096);
	mmap((void *)addr,4096, PROT_READ|PROT_WRITE|PROT_EXEC,
	     MAP_PRIVATE|MAP_ANON,-1,0); }}}}