Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Jul 1999 14:53:43 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Noriyuki Soda <soda@sra.co.jp>
Cc:        Jason Thorpe <thorpej@nas.nasa.gov>, "Brian F. Feldman" <green@FreeBSD.ORG>, bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org
Subject:   Re: Replacement for grep(1) (part 2) 
Message-ID:  <199907132153.OAA81153@apollo.backplane.com>
References:  <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp>

next in thread | previous in thread | raw e-mail | index | archive | help

:Running out of swap can be easily done by normal user privilege.
:Non-overcommiting system can run important application on the system
:which has a normal user, because it never lose critical data, even if
:a user on the system make a mistake. (The application might stop,
:but it never lose data.)
:
:4.4BSD derived system cannot do this, and have to use different
:machine for such applications.
:...
:
:8x or more?
:That's wrong. It depends.
:--
:soda

    If you are talking about a user intentionally attempting to run a system 
    out of swap, it is fairly easy to do whether the system uses an overcommit
    model or not.  The user has any number of ways of blowing the server up
    too - for example, by making thousands of connections to it or running
    many huge queries in parallel.

    A machine which is running a critical server is not a multi-user machine
    by definition, precisely because of this point.  No reservation model 
    will save you from a user hell-bent on screwing your machine up, there 
    are too many ways to do it.

    The reality is, again, that a properly configured system will not run out
    of swap.  Reliability is a statistical function... if the chance of
    a system running out of swap is 1 hour of down time per thousand years,
    that is a probability that can be ignored because there are plenty of
    other potential problems that will result in more down time.

    					-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?199907132153.OAA81153>