[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: malloc problem

On Thu, 12 Sep 2002, Akshay Adhikari wrote:
> > You only have so much memory to allocate and when you haven't
> > got any more the kernel will kill some process to free some
> > (I've heard of some kernel setting that doesn't kill on malloc
> > but waits until the memory is actually used).
> but why wouldnt it be possible in this case to simply return null from
> malloc?

When the malloc is done, no memory is allocated, it is only allocated when 
you write to it. Whether the system allows you to allocate more memory for 
processes than can fit in RAM without swapping or not is called overcommit 
and is configurable. If you run with overcommit, you'll get the OOM 
situations inside the programs and not in malloc, which can be troublesome 
but sometimes you don't want programs that allocate a lot and use a little 
to cause OOM situations either so you have to choose.. see 

Basically you echo 0 > /proc/sys/vm/overcommit_memory but I think this is 
default anyway.

Even if overcommit is disabled, you can of course still get OOM'ed because 
the malloc might fit but the next ethernet packet to be received might 
not... you should not use exactly all memory in an embedded linux system 
without swap.

> > I'm not sure about how the 2.4 kernel handles fragmentation,
> > but I think that if you fragment the memory you will increase
> > the possibility that a large malloc will fail.

No, the memory used for user-space memory can't be fragmented. It is not 
an issue since user-space memory need never be contiguous physically.

You can of course accidentally fragment the _physical_ memory from _inside_ 
the kernel to the degree that there are no empty pages left but that is an 
extreme case :)