Messages in this thread | | | Date | Fri, 17 Mar 2000 11:22:57 +0000 (GMT) | From | James Sutherland <> | Subject | Re: 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/
| |