Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!necntc!adelie!munsell!jwf
From: jwf@munsell.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: valloc() & mmap() on SUN's
Message-ID: <424@wyszecki.munsell.UUCP>
Date: Thu, 12-Mar-87 16:30:20 EST
Article-I.D.: wyszecki.424
Posted: Thu Mar 12 16:30:20 1987
Date-Received: Fri, 13-Mar-87 22:47:18 EST
Organization: Eikonix Corp., Bedford, MA
Lines: 32

Concerning valloc() and mmap() on a SUN, lee@srs.UUCP (Lee Hasiuk) writes:

> Since malloc() calls sbrk() and the kernel calls swapexpand() in the code
> which handles sbrk(), Sun claims that you need the space on your swap
> device which is as big as the area that you are going to map.  HOWEVER,
> the code for mmap ACTUALLY FREES THE SWAP AREA of the pages which get
> mapped, so that if you map your frame buffer a megabyte at a time, for
> example, you would only need one meg of free swap area to work with.  You
> shouldn't use valloc to do this, however, if you want the areas to be
> contiguous in the virtual address space of your process.  Instead, you
> should call sbrk() yourself.

Unfortunately, SUN 3.0 only supports *one* hole in the user virtual
space, i.e., one range of pages that do not have corresponding swap
space.  So only the first mmap() frees up swap space, subsequent ones do
the requested mapping but leave the swap space allocated.  This is ugly
and not very useful.

The hole (if any) is kept track of in the u. structure:

	struct	hole {		  /* a data space hole (no swap space) */
		int	uh_first; /* first data page in hole */
		int	uh_last;  /* last data page in hole */
	} u_hole;

Note that this is a single structure, not a linked list.  So there is no
mechanism to record a number of holes in the virtual space.
-----
{harvard!adelie,{decvax,allegra,talcott}!encore}!munsell!jwf

Jim Franklin, Eikonix Corp., 23 Crosby Drive, Bedford, MA 01730
Phone: (617) 275-5070 x415