> -----Original Message-----
> From: Daniel C. Sobral [SMTP:[email protected]]
> Sent: Wednesday, April 14, 1999 3:04 PM
> To: Ladavac Marino
> Cc: '[email protected]'; [email protected]
> 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)
> [email protected]
> [email protected]
>
> "nothing better than the ability to perform cunning linguistics"
>
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-current" in the body of the message
