Date: Wed, 14 Apr 1999 04:06:12 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: Ladavac Marino <mladavac@metropolitan.at> Cc: "'mi@aldan.algebra.com'" <mi@aldan.algebra.com>, current@FreeBSD.ORG Subject: RE: swap-related problems Message-ID: <Pine.BSF.3.96.990414035810.4169g-100000@cygnus.rush.net> In-Reply-To: <55586E7391ACD211B9730000C11002761795E9@r-lmh-wi-100.corpnet.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990414035810.4169g-100000>