Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.internals
Subject: Re: whay can't processes shrink as well as grow?
Message-ID: <26933@mimsy.umd.edu>
Date: 11 Oct 90 03:49:55 GMT
References: <1990Oct3.225943.4691@brolga.cc.uq.oz.au> <PCG.90Oct10212600@odin.cs.aber.ac.uk>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <PCG.90Oct10212600@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk
(Piercarlo Grandi) writes:
>Now there is a catch: even if your storage reclaimer detectes that a
>block of memory just under the break has become free, and lowers the
>break as a result, in many UNIX kernels this regrettably will not
>release any pages to the kernel mmeory pool ....

(from /sys/kern/vm_drum.c in the 4.{1,2,3,3-tahoe,3-reno} system:)

/*
 * Expand or contract the virtual swap segment mapped
 * by the argument diskmap so as to just allow the given size.
 *
 * FOR NOW CANT RELEASE UNLESS SHRINKING TO ZERO, SINCE PAGEOUTS MAY
 * BE IN PROGRESS... TYPICALLY NEVER SHRINK ANYWAYS, SO DOESNT MATTER MUCH
 */
vsexpand(vssize, dmp, canshrink)
	register segsz_t vssize;
	register struct dmap *dmp;
{
	...
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris