lkml.org 
[lkml]   [2000]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommitable memory??
On Fri, 17 Mar 2000, Andreas Bombe wrote:

> On Wed, Mar 15, 2000 at 10:36:21PM +0000, James Sutherland wrote:
> > On 15 Mar 2000, Rask Ingemann Lambertsen wrote:
> >
> > > Den 13-Mar-00 22:26:50 skrev James Sutherland følgende om "Re: Overcommitable memory??":
> > > > On Mon, 13 Mar 2000, Michael Bacarella wrote:
> > > >> There's no reason to tell an application that it has X megs of memory all
> > > >> to itself to play with, and then KILL one of it's brothers if the kernel
> > > >> finds itself short.
> > >
> > > > We don't "tell" any application we have X Mb of RAM.
> > >
> > > Actually, we do. If malloc (262144) returns non-zero, then we've told
> > > the application that we have 256 kB of memory, implemented as RAM or swap
> > > in any combination the kernel sees fit, as long as there is 256 kB in total.
> >
> > No, we have GIVEN it 256K of RAM. We don't say "We've got 255Mb of RAM,
> > how much would you like?", the app says "I need 17384Kb of RAM to operate.
> > Can I have it please?". Either the kernel says "yes", and it works, or it
> > says "no", and the app gives up.
> >
> > The problems occur when it decides it would like another chunk of RAM, and
> > is told it can't have it - at which point (since it only asked because it
> > NEEDED the RAM) it will almost always have to give up.
> >
> > We NEVER allocate memory via malloc() and then later discover we can't
> > honour that allocation - once the memory has been allocated, it is the
> > property of that process, to do with as it pleases.
>
> malloc(3) is a libc function. It may reuse free(3)d memory if there
> is a chunk of sufficient size, otherwise it uses brk(2) to expand the
> heap. The new pages aren't actually allocated until written to
> (unless mlockall() was called).
>
> Once written to, the new area gets faulted in through the COW
> handler. So it is possible that malloc succceeds without the memory
> being available later on (when overcommit is disabled the brk(2) will
> only succeed when the _current_ situation allows the new area to be
> faulted in completely).

Yes. You can avoid this by simply touching the memory when it is
allocated. You could, for example, allocate a small "emergency" buffer at
initialisation, touch it (so you know it is there and safe to use), then
(on receipt of a SIGTERM) exit gracefully, using this space for any
buffers etc. needed.

It's not just an OOM situation that could cause your process to be killed
this way; a routine shutdown will SIGTERM you, for example, as would (I
think) an imminent power failure signal from a UPS? In all these cases,
you want to exit as cleanly and quickly as possible, without any lost
data.


James.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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