Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Apr 1999 17:25:15 -0400 (EDT)
From:      Chuck Robey <chuckr@picnic.mat.net>
To:        Anthony Kimball <alk@pobox.com>
Cc:        dcs@newsguy.com, chat@FreeBSD.ORG
Subject:   Re: swap-related problems
Message-ID:  <Pine.BSF.4.10.9904151712580.18456-100000@picnic.mat.net>
In-Reply-To: <14102.16644.178732.291963@avalon.east>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Apr 1999, Anthony Kimball wrote:

> Quoth Chuck Robey on Thu, 15 April:
> 
> : > I understand this.  I concieve the purpose of this thread as being
> : > a clear determination of the best known way to allow correctly 
> : > written code to run reliably when, for reasons perhaps out of the
> : > control of the application, memory becomes overcommitted.
> : 
> : It might have been that, if on the second line of your original post you
> : didn't claim we were ANSI incompatible.  As it was, it sounded much like
> : chicken little yelling the sky was falling.  Your position now seems to
> : have changed quite a bit.
> 
> I'm glad to be corrected where I err.  But we are ANSI incompatible

No, we are not.  Malloc does in fact fail on those conditions.  There
are additional failures brought on by the OS when some other, possibly
unconnected process uses up all your memory, and this is quite
thoroughly outside the purview of the ANSI C spec.  mi has been told
this numerous times, and simply likes to ignore it.

The OS simply hunts for the biggest memory hog and kills it.  It can't
give a signal other than kill, because it' is out of memory, and MUST
correct that situation immediately, it can't hunt down the offender
(which would be quite difficult) and rely on the offender immediately
exiting.  It MUST free some memory.  This is totally outside the purview
of the spec, which we are in compliance with.

Sheesh.  I'm dropping this thread, if I see one more post from mi where
it's obvious he hasn't bothered to read a response, I'll embarrass
myself and get mad.  What gets me is, the work done to get our memory
overcommit working has given us a great, truly great VM situation, and
you guys are pretty obviously shooting at it without much understanding.
How a hobbyist-built system got so sophisticated amazes me.


----------------------------+-----------------------------------------------
Chuck Robey                 | Interests include any kind of voice or data 
chuckr@picnic.mat.net       | communications topic, C programming, and Unix.
213 Lakeside Drive Apt T-1  |
Greenbelt, MD 20770         | I run picnic (FreeBSD-current)
(301) 220-2114              | and jaunt (Solaris7).
----------------------------+-----------------------------------------------






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" 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.9904151712580.18456-100000>