From owner-freebsd-hackers Wed Jul 14 13: 9:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vtn1.victoria.tc.ca (vtn1.victoria.tc.ca [199.60.222.3]) by hub.freebsd.org (Postfix) with ESMTP id 9A9ED15474 for ; Wed, 14 Jul 1999 13:09:32 -0700 (PDT) (envelope-from jnemeth@vtn1.victoria.tc.ca) Received: (from jnemeth@localhost) by vtn1.victoria.tc.ca (8.8.8/8.8.8) id NAA22442; Wed, 14 Jul 1999 13:09:01 -0700 (PDT) Message-Id: <199907142009.NAA22442@vtn1.victoria.tc.ca> From: jnemeth@victoria.tc.ca (John Nemeth) Date: Wed, 14 Jul 1999 13:09:01 -0700 In-Reply-To: Ben Rosengart "Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))" (Jul 14, 5:57pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ben Rosengart Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 14, 5:57pm, Ben Rosengart wrote: } On Wed, 14 Jul 1999, John Nemeth wrote: } } > On one system I administrate, the largest process is typically } > rpc.nisd (the NIS+ server daemon). Killing that process would be a } > bad thing (TM). You're talking about killing random processes. This } > is no way to run a system. It is not possible for any arbitrary } > decision to always hit the correct process. That is a decision that } > must be made by a competent admin. This is the biggest argument } > against overcommit: there is no way to gracefully recover from an } > out of memory situation, and that makes for an unreliable system. } } $DEITY on a pogo stick, how many times do we have to hear the same } hypothetical argument? It is not hypothetical in any way. The fact that you refuse to believe the examples given is your problem. } Tell me, Mr. Nemeth, has this ever happened to you? Have you ever come } *close*? The machine in question has run out of swap, due to unforseeable excessive memory demands. This was accompanied by processes complaining about not being able to allocate memory and then cleaning up after themselves. I did not see random processes being killed because of it. That is the way things should be. From this, I can assume that the OS doesn't overcommit. In case, you're wondering, the OS in question is: SunOS 5.5 Generic_103093-25 sun4u sparc }-- End of excerpt from Ben Rosengart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message