Subject: Re: userid partitioned swap spaces.
To: None <tech-kern@netbsd.org>
From: Ian Dall <Ian.Dall@dsto.defence.gov.au>
List: tech-kern
Date: 12/17/1998 10:56:07
woods@most.weird.com (Greg A. Woods) writes:

  > [ On Wed, December 16, 1998 at 01:14:59 (-0800), John Nemeth wrote: ]
  >> Subject: Re: userid partitioned swap spaces.
  >> 
  >> memory more efficiently, some "brilliant" person invented
  >> overcommitting of memory (I believe this was done in SysV).

  > I don't know when SysV adopted this policy, if indeed it ever has (I'm
  > fairly certain SysVr4.0 never over-committed swap)

It was there in SysVr2.2. As far as I know it hasn't been taken out.

Noriyuki Soda <soda@sra.co.jp> writes:

  >> b) Many modern databases depend on efficiently handled sparse data
  >> structures.

  > Almost all commercial UNIX are non-over-commiting systems,
  > so this should not be problem.

If this is true then I am very suprised. Given their heritage, I would
expect that anything based on SysV, mach or BSD 4.4 (which is nearly
everything unix like) would over commit, but don't know for sure that
it hasn't been "fixed".

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.

The simplest thing to do is top allow a portion of swap which can only
be used by root like only root can use more than 100% of a ffs file
system.  Any non process needing swap when the high tide mark has been
reached is suspended. This allows important daemons to continue and
also for root to fix things, presumably by taking a human decision to
kill something, but also possibly adding more swap. This doesn't buy
much on a workstation with only the console for interaction if the
console is running a non root X server. But there high tide which only
root can exceed does provide a mechanism on which it is possible to
overlay more friendly mechanisms. A suid interactive process killer
could be written for non root users to kill their own processes etc.

Of course, this is a special case of per user swap, and a fully
general facility for allocating swap on a per person basis would be
more elegant if it can be done efficiently and without excessive work.

Ian