hi again :) 2011/10/14 Ezequiel García <elezegarcia@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