Date: Wed, 14 Jul 1999 12:33:00 -0600 From: lyndon@orthanc.ab.ca To: "Brian F. Feldman" <green@FreeBSD.ORG> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <199907141833.MAA05320@orthanc.ab.ca> In-Reply-To: Your message of "Wed, 14 Jul 1999 12:00:55 EDT." <Pine.BSF.4.10.9907141159400.9606-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907141833.MAA05320>