> 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
