Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Jul 1999 16:16:46 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Ted Faber <faber@ISI.EDU>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Replacement for grep(1) (part 2) 
Message-ID:  <199907132316.QAA81828@apollo.backplane.com>
References:   <199907132309.QAA01587@boreas.isi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

:So, Matt, I understand that you think that the folks who are want to
:turn off overcommit are looking to hang themselves, but how much does
:it cost to sell them the rope?
:
:Would adding the sysctl to turn off overcommit be a costly,
:time-consuming hunk of work, or a three-line patch?  If it's the
:latter, why not provide the functionality?  (Obviously if there's
:significant new work and complexity involved, changing the status quo
:demands proving a string case.)
:
:I don't have the knowledge of the VM system to answer the question; I
:can imagine a system with one or two VM allocation routines where the
:change would be trivial, and a more complex system where it would be
:very difficult.  Which one do I run? :-)
:
:- ----------------------------------------------------------------------
:Ted Faber                                                faber@isi.edu
:USC/ISI Computer Scientist                   http://www.isi.edu/~faber
:(310) 822-1511 x190      PGP Key: http://www.isi.edu/~faber/pubkey.asc

    I'm guessing that a simple implementation would be about an hour's
    worth of work on the kernel:  Basically keeping track of MAP_PRIVATE
    maps and summing up their total size verses the amount of main memory
    and swap available, minus some fudge factor.

    But you would never be able to run normal system programs reliably
    without also going through the entire utility source base and doing a 
    whole lot of rewriting.  Standard programs such as 
    <everything_under_the_sun> are not going to be happy when the limit is
    hit and this will slowly cause system daemons to disappear from the
    system and for programs to start dying in odd ways when you do anything
    that brings the system close to an 'overcommitted' state.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907132316.QAA81828>