Date: Wed, 14 Jul 1999 21:28:34 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: D.Thomas@vthrc.uq.edu.au (Danny Thomas) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit Message-ID: <199907150428.VAA06718@apollo.backplane.com> References: <v02140b06b3b283d51ab3@[130.102.4.80]>
next in thread | previous in thread | raw e-mail | index | archive | help
:Ted Faber <faber@ISI.EDU>
:>For every strategy there's a counterstrategy.
:exactly: the disappointing thing about this whole thread is there's been
:little discussion of implementing a (tunable) policy how to handle the
:situation when resource shortage materialises.
:
:Overcommitment can be useful, maybe even for most people...
:
:>Killing the biggest is simple to implement and usually right.
:... but some people don't want that policy, at least on some of their
:systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously
:absent from discussion, which might have taken things into a more
:productive vein. What do other over-committing systems offer?
:
:Danny Thomas
Here's an alternative:
whlie (1)
sleep 60
blah blah blah run pstat -s, get available swap.
if available swap < 200MB then
blow away some non-critical processes
if no non-critical processes remain
blow away everything not owned by root and
yell for help.
if no no-root processes remain
do nothing. let the kernel blow away
the biggest process when swap actually
runs out.
endif
endif
endif
end
How long do you suppose it would take to actually write that
script? One hour? Two hours? Not long, I think.
Problem solved.
-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?199907150428.VAA06718>