ENOMEM failure on mmap call

[Mulyadi Santosa]

Hi Ezequiel :)

2011/10/11 Ezequiel García <elezegarcia at yahoo.com.ar>:
> Hi,
>
> I have a SH4 board:

Alright, I use x86 for the basis of my (guessing) answer, so things
might vary... :)

> and suppose I have eaten pretty much all the memory, and have only 9 MB left (aprox.)
>
> $ free
>  total       used       free     shared    buffers     cached
> Mem:         48072      42276       5796          0        172       3264
> -/+ buffers/cache:      38840       9232
> Swap:            0          0          0

so, excluding page cache aside, you had 9232 kilobytes = 9 MB free RAM.

> ulimit -s 7500
> I can now launch 10 threads. Each thread does not allocate anything, so it is only consuming the minimum overhead (aprox. 8 kb per thread, right?).

8MB failed, roughly 7.5 MB success....0.5 difference...

> So, my question is:
>
> Knowing that mmap doesnt actually consume the memory (due to overcommit=0, right?):

I guess this has somewhat a relation with OOM (Out of Memory
detection). The thing is, even though mmap() doesn't allocate anything
initially, but still you commit a memory area. And kernel, in this
case, will promise up to certain degree that it will satisfy your
request at its best.

Initially, you requested 8 MB. Knowing that you had 9 MB free RAM, I
think you got ENOMEM since that would just leave 1 MB and quite likely
that is under safe minimum free RAM allowed. I roughly recall that
somewhere around 2-5% of RAM must be kept unallocated from user need
to cope with urgent situation or something like that.

It was shown that, when you use 7.5 MB, that slight 0.5 MB made you
didn't hit the mark...so you're safe now and kernel allow that.

Sorry I couldn't point you to exact kernel source code line.
lxr.linux.no is your best friend....

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

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