Re: Overcommitable memory??

From: Andreas Bombe (andreas.bombe@munich.netsurf.de)
Date: Thu Mar 16 2000 - 18:44:48 EST


On Thu, Mar 16, 2000 at 11:22:17AM +0000, Paul Jakma wrote:
> On Thu, 16 Mar 2000, James Sutherland wrote:
>
> > On Wed, 15 Mar 2000, Paul Jakma wrote:
>
> > That doesn't happen. malloc() ALLOCATES the memory to the process. It is
> > *NOT* overcommitted. It may be backed by swapspace rather than physical
> > memory, but that block of memory *IS* available to the process.
> >
>
> so malloc() isn't overcommited? malloc()'ed memory is guaranteed to be
> available - ie the memory is reserved and accounted for at malloc()
> time?
>
> (i always thought malloc()'s were noted by the kernel ie in the page
> table for the process, but that the kernel didn't actually allocate a
> real page until the process tried to access that page - ie malloc() is
> overcommited)

Looking at the sources of do_brk(), it faults in the pages (thereby
assuring they will exist for the process) only if the process' VM is
locked (mlockall()). Also, it returns with ENOMEM only[1] if
vm_enough_memory() says there isn't enough mem, but this function only
examines a snapshot of mem usage at the time of the call (and is
always successful if overcommit is set to on).

Unless I misunderstand the sources (I'm not a Linux VM expert), malloc
will overcommit.

[1] Well, not only, it also checks for rlimits and a few other things
    not related to real memory.

-- 
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

- 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/



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:21 EST