Date: Fri, 25 Jul 2003 07:50:20 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Matthias Buelow <mkb@mukappabeta.de> Cc: freebsd-stable@freebsd.org Subject: Re: malloc does not return null when out of memory Message-ID: <20030724215020.GV430@gsmx07.alcatel.com.au> In-Reply-To: <3F1F45E2.5080506@mukappabeta.de> 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> <3F1F45E2.5080506@mukappabeta.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-Jul-24 04:35:14 +0200, Matthias Buelow <mkb@mukappabeta.de> wrote: >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)? Have a look at how systat(1) or top(1) calculate the number they report. AFAIK, the kernel doesn't accumulate this information into a single total or make use of it in VM allocation decisions. > And is it planned in the (distant) >future to add a knob to toggle overcommitting of swap? All I can say is I'm unaware of any such plan. Based on the previous threads, the VM experts appear to be either against this or don't see any benefit. > 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. This comes up every time this thread starts. As I said before - read the archives. If you think you have a solution that works and avoids at least the larger pitfalls (see the archives), you need to provide patches (or show a willingness to pay someone else to write the code). Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724215020.GV430>