On Wed, 14 Apr 1999, Alfred Perlstein wrote:
> On Wed, 14 Apr 1999, Ladavac Marino wrote:
>
> > > -----Original Message-----
> > > From: Mikhail Teterin [SMTP:m...@misha.cisco.com]
> > > Sent: Wednesday, April 14, 1999 12:45 AM
> > > To: curr...@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" ?
This isn't really a great idea since it would be changing the Unix
API. However, I agree that processes with exclusive use of the video
hardware should not be killed by the system *COUGH XFree86 COUGH*.
>
> -Alfred
>
> >
> > It would be nice if memory overcommit were configurable (on-off,
> > or per process).
> >
> > /Marino
> >
> >
> > To Unsubscribe: send mail to majord...@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 majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman _ __ ___ ____ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
http://www.freebsd.org _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
