From owner-freebsd-current Thu Apr 15 16:57:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 98EC314A2F for ; Thu, 15 Apr 1999 16:57:24 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA14648; Thu, 15 Apr 1999 16:49:36 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA03806; Thu, 15 Apr 1999 16:49:35 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA11653; Thu, 15 Apr 1999 16:49:34 -0700 (PDT) From: Don Lewis Message-Id: <199904152349.QAA11653@salsa.gv.tsc.tdk.com> Date: Thu, 15 Apr 1999 16:49:33 -0700 In-Reply-To: Chuck Robey "Re: swap-related problems" (Apr 14, 4:40pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Chuck Robey , Anthony Kimball Subject: Re: swap-related problems Cc: phk@critter.freebsd.dk, current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 14, 4:40pm, Chuck Robey wrote: } Subject: Re: swap-related problems } On Wed, 14 Apr 1999, Anthony Kimball wrote: } > Well, it's only needed if you want to be able to reliably execute ANSI } > C code according to spec. I personally don't care. I'd be surprised } > if core didn't though. I would suspect that it would be deemed worthy } > of someone's p2 queue, at least. } } I can't understand this. Make software that causes a major performance } loss, and loses *bigtime* in memory allocation, just so the one guy to } complain *at all* can not lose sleep over something that has causes no } problems at all with any ANSI code in a properly sized system. SunOS 4 doesn't do memory overcommit. I've been running large processes for years on SunOS 4 machines and haven't noticed any performance problems due to lack of memory overcommit. You just need to configure plenty of swap. I've found the old 3x RAM rule works fine, and it's really cheap these days. This could be shaved down a bit if SunOS didn't require (swap > total VM) instead of (swap + RAM > total VM). If you want to talk about slow, there are those crufty old implementations that don't have COW fork(). If a large process forks, its entire memory space needs to be duplicated, which is *really slow* if the process was too big to fit in RAM to begin with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message