From owner-freebsd-current Wed Apr 14 9: 3:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id DE7B01548D for ; Wed, 14 Apr 1999 09:03:01 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id <26KYCYR9>; Wed, 14 Apr 1999 18:03:14 +0200 Message-ID: <55586E7391ACD211B9730000C11002761795EA@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: "'Daniel C. Sobral'" , Ladavac Marino Cc: "'mi@aldan.algebra.com'" , current@FreeBSD.ORG Subject: RE: swap-related problems Date: Wed, 14 Apr 1999 17:59:21 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----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