From owner-freebsd-current Wed Apr 14 1:55:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id A6C8114E59 for ; Wed, 14 Apr 1999 01:55:11 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id EAA19725; Wed, 14 Apr 1999 04:06:16 -0500 (EST) Date: Wed, 14 Apr 1999 04:06:12 -0500 (EST) From: Alfred Perlstein To: Ladavac Marino Cc: "'mi@aldan.algebra.com'" , current@FreeBSD.ORG Subject: RE: swap-related problems In-Reply-To: <55586E7391ACD211B9730000C11002761795E9@r-lmh-wi-100.corpnet.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Apr 1999, Ladavac Marino wrote: > > -----Original Message----- > > From: Mikhail Teterin [SMTP:mi@misha.cisco.com] > > Sent: Wednesday, April 14, 1999 12:45 AM > > To: current@freebsd.org > > Subject: Re: swap-related problems > > > > > > Well, this is just an implementation detail, is not it? I don't > > mean to critisize, or anything, but such thing as "no available > > memory" is a fairly intuitive... Coming down, again, the malloc > > should return a usable memory if available and NULL if it's not. > > Is not this a "natural" semantics? Why can a program die because > > _another_ program ate up all the rest of the memory? > > > > > [ML] This is a common problem for any OS that implements memory > overcommit. This means that it is not possible to detect an out-of-swap > condition sinchronously as the swap is reserved only when the pages are > dirtied and not when brk is grown. This means that you can set brk a > gigabyte higher (given that your user limits allow that), and you will > not be using swap as long as you do not write to the pages you > "allocated" to the process. > > 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. An interesting idea would be to mark this process as killable if COW causes an out of swap condition. Another interesting application would be a fork() call that checks this condition and fails if there is potential for overcommit. forkifavail() Basically anyone doing a system("date"); should be using vfork (yes i can see when vfork is not sufficient) This would sort of be like a soft limit on memory allocation and hint to the kernel of which processes are the ones causeing overcommit. basically at a certain point, sbrk will fail and forked processes would be marked killable... does this make sense? has the idea of processes running with uid < 10 or just root being excempt from this "frantic kill" ? -Alfred > > It would be nice if memory overcommit were configurable (on-off, > or per process). > > /Marino > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Alfred Perlstein - Admin, coder, and admirer of all things BSD. -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 4.0-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message