Skip site navigation (1)Skip section navigation (2)
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>