Date: Wed, 14 Jul 1999 12:00:55 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: "Charles M. Hannum" <root@ihack.net>, Matthew Dillon <dillon@apollo.backplane.com>, Noriyuki Soda <soda@sra.co.jp>, Jason Thorpe <thorpej@nas.nasa.gov>, bright@rush.net, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <Pine.BSF.4.10.9907141159400.9606-100000@janus.syracuse.net> In-Reply-To: <378CAAD9.AAD7268E@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Jul 1999, Daniel C. Sobral wrote:
> "Charles M. Hannum" wrote:
> >
> > That's also objectively false. Most such environments I've had
> > experience with are, in fact, multi-user systems. As you've pointed
> > out yourself, there is no combination of resource limits and whatnot
> > that are guaranteed to prevent `crashing' a multi-user system due to
> > overcommit. My simulation should not be axed because of a bug in
> > someone else's program. (This is also not hypothetical. There was a
> > bug in one version of bash that caused it to consume all the memory it
> > could and then fall over.)
>
> In which case the program that consumed all memory will be killed.
> The program killed is +NOT+ the one demanding memory, it's the one
> with most of it.
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.
>
> --
> Daniel C. Sobral (8-DCS)
> dcs@newsguy.com
> dcs@freebsd.org
>
> "Would you like to go out with me?"
> "I'd love to."
> "Oh, well, n... err... would you?... ahh... huh... what do I do
> next?"
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
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?Pine.BSF.4.10.9907141159400.9606-100000>