Date: Thu, 24 Jul 2003 04:35:14 +0200 From: Matthias Buelow <mkb@mukappabeta.de> To: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory Message-ID: <3F1F45E2.5080506@mukappabeta.de> In-Reply-To: <20030724021726.GJ430@gsmx07.alcatel.com.au> References: <20030723173427.GA72876@vmunix.com> <20030723140329.C92624@carver.gumbysoft.com> <20030723221336.GA26555@pit.databus.com> <20030723223654.GA24008@moghedien.mukappabeta.net> <20030723224436.GD22166@Odin.AC.HMC.Edu> <20030724021726.GJ430@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> FreeBSD behaviour in the face of swap shortage is a regular and
> popular discussion topic. I suggest that a perusal of the archives
> will probably answer any questions. If anyone wishes to suggest a
> "solution" to FreeBSD's behaviour when there is a shortage of swap,
> please include patches.
What makes me ask the following (note that it's neither a flame, nor a
suggestion). Does FreeBSD actually account the used swap/vm so far (it
needn't since it doesn't guarantee that it'll be available, with
overcommit) or does it not do that (i.e., it has no idea of how much vm
was requested by all processes so far, without having to go through the
maps of all processes, of course)? And is it planned in the (distant)
future to add a knob to toggle overcommitting of swap? While with large
disks and hence swap sizes this probably isn't a pressing problem for
most applications, it might be nice to be able to control the system not
to randomly kill off applications or force the user to meticulously
plan and calculate memory load of the planned application zoo in order
to tune the ulimits of various memory-hungry processes in a way that
they'll all fit into swap in the worst case situation.
--
Matthias Buelow; mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F1F45E2.5080506>