From owner-freebsd-hackers Tue Jul 13 16:18: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2705414DF9 for ; Tue, 13 Jul 1999 16:18:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA81828; Tue, 13 Jul 1999 16:16:46 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 16:16:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132316.QAA81828@apollo.backplane.com> To: Ted Faber Cc: hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132309.QAA01587@boreas.isi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message