Date: Tue, 13 Jul 1999 12:46:39 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: cgd@netbsd.org (Chris G. Demetriou) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907131946.MAA80310@apollo.backplane.com> References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> <873dys1hfw.fsf@redmail.redback.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> have to allocate anyway if we were to actually disallow overcommits! But
:> with overcommits allowed, your box will never come close to using that
:> much swap.
:
:This may be a decent answer for the workstation world, but it's not so
:good for more restricted systems. Further, your claim that
:disallowing overcommit gains you absolutely nothing is simply false.
:
:It gains you two things (which are at least immediately obvious to me):
:
:* Certain knowledge that (if the system is implemented correctly) the
: system will never have to kill a process (or take similar corrective
: action) due to overcommit, and that attempts to allocate more backing
: store resources than are present will fail.
By the time the system reaches the point where it would have to do
this in the case where you reserve sufficient swap to handle a
situation where overcommits would not be allowed, the system will
*ALREADY BE DEAD*.
Please read my other posting carefully. Certain knowledge doesn't
help you if the system becomes unuseable first.
Swap overcommit is a non-problem.
:* protection against bogosity.
:
: I may run a system in which all of the processes are effectively
: unlimited (i.e. have huge resource limits), but I know within a
: tolerance what the actual expected usage of the system is.
Set a resource limit that is, say, 1/2 your swap space. Problem
solved.
Of course there are plenty of potential situations where this will
not work... what if two processes run away? What if 10 processes
run away? What if they ALL run away? But the reality is that you
can think up these potentialities until you are blue in the face and
you will never solve your problem. Even advocating a system which
does not allow overcommit will not solve your problem... the result
of that will be a system which starts refusing to do things long before
it would otherwise. This is unacceptable.
You have to think of the problem in terms of what will realistically
occur in a system. Trying to solve any other problem will not help
make the system more reliable. You will wind up running in circles trying
to solve problems that never occur instead of solving the problems that
do occur.
:cgd
:--
:Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199907131946.MAA80310>