From owner-freebsd-hackers Wed Jul 14 11:33: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id B609415421; Wed, 14 Jul 1999 11:33:01 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id MAA05320; Wed, 14 Jul 1999 12:33:01 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141833.MAA05320@orthanc.ab.ca> To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Wed, 14 Jul 1999 12:00:55 EDT." Date: Wed, 14 Jul 1999 12:33:00 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So why don't we do something else: when we're down to a certain amount of > backing store, start collecting statistics. When we're out, we check the > statistics and find what process has been allocating most of it. We kill > that process. Our IMAP server routinely show a footprint of about 1MB private storage. This is constant for most operations. However, when you get into doing SEARCH and SORT, there are certain cases where we need memory, sometimes a *lot* of memory. Your proposal is that my *well behaved* application should be arbitrarily killed, leaving the client stuck with a) no results and b) no IMAP connection, in this situation. (And think threaded. That one server could be handling *hundreds* of clients.) This is preferable to returning a NULL to the malloc() request, which I can handle gracefully by simply returning a NO response to the IMAP client? What it so evil about having a reasonably intelligent malloc() that tells the truth, and returns unused memory to the system? Overcommit is for lazy programmers, plain and simple. At least the SGI documentation about overcommit admits that (or at least, did at one time). --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message