Date: Wed, 14 Apr 1999 09:38:42 +0200 From: Ladavac Marino <mladavac@metropolitan.at> To: "'mi@aldan.algebra.com'" <mi@aldan.algebra.com>, current@freebsd.org Subject: RE: swap-related problems Message-ID: <55586E7391ACD211B9730000C11002761795E9@r-lmh-wi-100.corpnet.at>
next in thread | raw e-mail | index | archive | help
> -----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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55586E7391ACD211B9730000C11002761795E9>