ENOMEM failure on mmap call

[Mulyadi Santosa]

hi again :)

2011/10/14 Ezequiel García <elezegarcia at yahoo.com.ar>:
> Reading sources I think kernel let the process create several
> threads because as there is no real memory usage, the amount of free pages
> on each thread allocation is the same.

I agree, as long as Copy on Write hasn't kicked in.... sometimes it's
the commited amount of memory that matters, sometimes how much memory
you really allocate that matters.

Around 2006, I wrote an article about Out of Memory killer, somehow
related to this issue. Maybe you are interested to read it:
http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html

> I mean, when I start first thread I have enough free pages to allow
> the mmap(). When I start the second, third, etc. I always have the
> same amount of free pages, since threads don't alloc any pages they
> just 'prepare' the adresses.
So, the stack area is shared among those threads?

> I'll try to put some printk inside vm_enough_memory() and try to re-run
> my tests. Do you think there is any other debugging aproach?

IMO, that one way to go :) of course nowadays you have ftrace etc, but
still, printk followed by kernel recompilation is still easiest IMHO
:)

> By the way, I have already solved my problem (weeks ago) by reducing default
> thread stack size :) But I would love to understand what happened.

Welcome to the OOM world :)

> It's a strange scenario for a linux kernel, since I have very low memory
> left and zero swap.

I think it's not that strange, we just have to understand the
behaviour. And perhaps your application must anticipate it by
gradually decreasing such memory allocation whenever you hit such
error.

> Thanks a lot for the help!
You welcome and sorry I don't lend too much help here...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com