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)
> d...@newsguy.com
> d...@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 _ __ ___ ____ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
