Subject: Re: userid partitioned swap spaces.
To: None <tech-kern@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-kern
Date: 12/16/1998 22:00:34
[ On Thu, December 17, 1998 at 10:56:07 (+1030), Ian Dall wrote: ]
> Subject: Re: userid partitioned swap spaces.
>
> It was there in SysVr2.2. As far as I know it hasn't been taken out.

Hmm.... strange.  My AT&T 3B2's never over-committed virtual memory
vs. swap, not with 3.0, nor 3.1, nor 3.2, and I'm pretty sure I've never
seen a SysVr4.0 machine that would either.  I know there were several
major changes in the VM somewhere between 4.0 and 4.2, but so far as I
know they only improved performance, with no degredation in stability
under extreme resource starvation.  My "UNIX Internals" and Bach books
and SysV manuals are still packed away so I can't give references right
now.

Perhaps we're talking about two different concepts.  When an AT&T UNIX
System V system with virtual memory runs out of "swap" space you can't
start a new process, or grow an existing one, but systems would run for
days banging their heads off the top of a full swap system -- nothing
would crash, nothing would die, and nothing would be killed (they just
won't be successfull if they try to sbrk(2) or fork(2), which may cause
some processes to give up, of course).  When I was running many full
news feeds on a little 3B2/400 with only 4MB RAM, I saw this happen
nearly every day until I got a slightly faster 3B2/500 with faster and
more disk and I didn't have to batch news at the same time expire was
running.

  Noriyuki Soda <soda@sra.co.jp> writes:
  > Almost all commercial UNIX are non-over-commiting systems,
  > so this should not be problem.

Indeed.  That's been my experience, with the exception of AIX and early
versions of Sequent Dynix and Pyramid OSx, and I suppose SunOS-3 (all of
which leaned far more towards 4BSD than any other commercial Unix, even
SunOS-4).

> For what its worth, I think being able to handle huge sparse arrays
> efficiently is attractive. The problem comes when this has been
> overlaid on a system which has only rudimentary controls on resource
> allocation.

Yes, I suppose so, but unless you're talking about *REALLY* big sparse
arrays, it's always safer, from a systems point of view, to always
reserve as much swap space as you could ever need.  The only cost is a
small amount of performance and of course the disk space you need to
dedicate to swap.  These days you can buy and awful lot of very fast
swap disk for less than it would cost to re-write an application to be
more memory efficient.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>