Date: Thu, 15 Apr 1999 16:49:33 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Chuck Robey <chuckr@picnic.mat.net>, Anthony Kimball <alk@pobox.com> Cc: phk@critter.freebsd.dk, current@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <199904152349.QAA11653@salsa.gv.tsc.tdk.com> In-Reply-To: Chuck Robey <chuckr@picnic.mat.net> "Re: swap-related problems" (Apr 14, 4:40pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904152349.QAA11653>