lkml.org 
[lkml]   [1997]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory overcommitting
-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 19 Feb 1997, Vance Huntley wrote:

> At 21:20 -0500 2/19/97, Sean Farley wrote:
> >Let's say that you wrote an application that must have control over any
> >demise of the application, i.e. database. Since we cannot make the
> >assumption that malloc will protect us from ourselves or another ruthless
> >program, what course should someone take to handle a more graceful
> >shutdown if the situation comes about? How does Linux kill off processes
> >when the memory is exhausted?
> >
> >Sean
> >-------
> >scf@tctc.com
>
> One strategy for such mission-critical apps would be to grab a sizable
> chunk of memory at initialization time as your emergency "cushion". Then
> install a signal handler for SEGV which:
> - releases the cushion, curing the memory shortage for the short term
> - shuts down your app
>
> or
> - sends your app into a special emergency shutdown which performs
> any cleanup routines using the memory inside your cushion
>
> The first plan has the disadvantage that other processes may steal the
> released cushion memory, leaving you without enough to clean up with.
>
> Vance
>
> PS - Of course, holding a large chunk of memory for the lifetime of the
> process without ever using it is exactly the kind of thing that would
> result in an overcommitted memory situation in the first place ;-)


And exactly what Linux's VM system takes care of. :-) To really make
suggestion #2 work you would need to write to each page of the memory to
make sure the kernel had secured all the pages you requested. Of course,
then you really WOULD be helping to facilitate overcommitment, of a nature
that the kernel can't do jack about. Still, it's not a bad idea for a
*critical* application, as long as you keep the allocations small
(shouldn't need much if everything is done right). Forturnately, not all
applications need this level of safety and can be perfectly happing
running in their usual ignorance. :-)

>
> ------------
> Vance Huntley
>
> Director of Technology (& Chat Guy)
> WebGenesis, Inc., Ithaca, NY 14850
>
> vance@webgenesis.com --- 607.255.8499
>
> Check out "The Globe"! --- http://www.theglobe.com/
> ------------
>
>

+-------------------------------------------------------------------+
+ -- Finger: flood@evcom.net for my PGP public key -- +
+-------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMwvewBsjWkWelde9AQHr/wQAlRf4+UyUFlVMO8Z9dA5ZcCv/172SodkR
3PAr9bboYqYA70faN86wtJBajIxdGbTkG6wxqDnkni4C3ZEpp9C3bZA/qgZ2kxsV
0F4tN/EyXYPIk1n5JSv8ONd8E241+Mc+uyoCk1veBCxkBRxHLh6XFhH792L6Yu12
1GRREufxA24=
=9wjO
-----END PGP SIGNATURE-----


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:1.755 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site