From owner-freebsd-hackers Wed Jul 14 21:37:21 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 E7E8E1513C for ; Wed, 14 Jul 1999 21:37:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA06766; Wed, 14 Jul 1999 21:37:08 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 21:37:08 -0700 (PDT) From: Matthew Dillon Message-Id: <199907150437.VAA06766@apollo.backplane.com> To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907141755.LAA05231@orthanc.ab.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I mean, jeeze, the reservation for the program stack alone would eat :> up all your available swap space! What is a reasonable stack size? The :> system defaults to 8MB. Do we rewrite every program to specify its own :> stack size? How do we account for architectural differences? : :The alternative is to rewrite every program that assumes the semantics :of malloc() are being followed. The problem I have as an applications :writer is that I tend to believe malloc. To pick a specific example, :our IMAP client takes steps to ensure it won't run out of memory in :critical sections. We maintain a "rainy day" pool block of memory. If :... :--lyndon We just put a cap on the number of imap clients we allow running at any given moment... say, a few hundred. Not only does it work just dandy, it also prevents the machine from overloading and gives us a nice "you may want to look into this" alarm. We do the same thing with sendmail, popper, the web server, named, and every other service which can be forked. This also prevents one subsystem from overly interfering with another. For example, if popper saturates it does not overly interfere with imapd operation. The limit is set to around 3x the monday peak load, and sufficient swap is configured to deal with it should the limit be hit. Problem solved. No fancy modifications required. If any of these subsystems actually ever got close to using all available swap, the other subsystems would be up the creek anyway so, really, it doesn't make much sense hacking the source to allow the subsystem to run into the wall anyway. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message