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