I am developing SW for embedded Linux and i am suffering system hangs because OOM Killer appears from time to time. Before going beyond i would like to solve some confusing issues about how Linux Kernel allocate dynamic memory assuming /proc/sys/vm/overcommit_memory has 0 and /proc/sys/vm/min_free_kbytes has 712, and no swap.

Supposing embedded Linux currently physical memory available is 5MB (5MB of free memory and there is not usable cached or buffered memory available) if i write this piece of code:

.....
#define MEGABYTE 1024*1024
.....
.....
void *ptr = NULL;
ptr = (void *) malloc(6*MEGABYTE); //Preserving 6MB
if (!prt) 
    exit(1);
memset(ptr, 1, MEGABYTE);
.....

I would like to know if when memset call is committed the kernel will try to allocate ~6MB or ~1MB (or min_free_kbytes multiple) in the physical memory space.

Right now there is about 9MB in my embedded device which has 32MB RAM. I check it by doing

# echo 3 > /proc/sys/vm/drop_caches 
# free
            total         used         free       shared      buffers
Mem:        23732        14184         9548            0          220
Swap:            0            0            0
Total:        23732        14184         9548

Forgetting last piece of C code, i would like to know if its possible that oom killer appears when for instance free memory is about >6MB. I want to know if the system is out of memory when oom appears, so i think i have two options:

  • See VmRSS entries in /proc/pid/status of suspicious process.

  • Set /proc/sys/vm/overcommit_memory = 2 and /proc/sys/vm/overcommit_memory = 75 and see if there is any process requiring more of physical memory available.


Solution 1:

I think you can read this document. Is provides you three small C programs that you can use to understand what happens with the different possible values of /proc/sys/vm/overcommit_memory .