Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Apr 1999 17:59:21 +0200
From:      Ladavac Marino <mladavac@metropolitan.at>
To:        "'Daniel C. Sobral'" <dcs@newsguy.com>, Ladavac Marino <mladavac@metropolitan.at>
Cc:        "'mi@aldan.algebra.com'" <mi@aldan.algebra.com>, current@FreeBSD.ORG
Subject:   RE: swap-related problems
Message-ID:  <55586E7391ACD211B9730000C11002761795EA@r-lmh-wi-100.corpnet.at>

next in thread | raw e-mail | index | archive | help

> -----Original Message-----
> From:	Daniel C. Sobral [SMTP:dcs@newsguy.com]
> Sent:	Wednesday, April 14, 1999 3:04 PM
> To:	Ladavac Marino
> Cc:	'mi@aldan.algebra.com'; current@FreeBSD.ORG
> Subject:	Re: swap-related problems
> 
> Ladavac Marino wrote:
> > 
> >         Another strategy is to reserve the swap space as soon as it
> is
> > allocated by the program.  This strategy is much more conservative
> and
> > inherently safer, but it needs much more space: for instance, if you
> > have a program with WSS of a gigabyte and you want to system( "date"
> ),
> > you will need at least 2 gigs of swap because system() does fork()
> first
> > which means that you get 2 copies of your big program and the system
> > cannot know that in one of the copies an exec() will be shortly
> > forthcoming--thus, it has to reserve the full WSS for the copy
> because
> > it will potentially write to all pages of its WSS.
> > 
> >         It would be nice if memory overcommit were configurable
> (on-off,
> > or per process).
> 
> On AIX, you can have it set as a global option and on/off per
> process. In my experience, though, setting it to off never solved
> anything: if you need memory, you have to add memory.
> 
	[ML]  Oh, memory overcommit does have its applications.
Remember the olden days of FORTRAN when "dynamic memory allocation" was
a meaningless term :)  Overcommit let the people "allocate" a
10000*10000 matrix and use only a 20*20 subset of it and have program
execute instead of fail out-of-swap.

	Nowadays, vfork() could solve most of the problems on fork/exec.
Sadly, a frightening number of unices "implement" vfork() as

	#define vfork fork

	/Marino
> --
> Daniel C. Sobral			(8-DCS)
> dcs@newsguy.com
> dcs@freebsd.org
> 
> 	"nothing better than the ability to perform cunning linguistics"
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55586E7391ACD211B9730000C11002761795EA>