Glance at the preceding output of our oom_killer_try app: (in this particular run) 33 periods (.) appear before the dreaded Killed message. In our code, we emit a . (via printf) every 5,000 times we make an allocation (of 2 pages or 8 KB). Thus, here, we have 33 times 5 periods, meaning 33 * 5 = 165 times => 165 * 5000 * 8K ~= 6,445 MB. Thus, we can conclude that, after our process (virtually) allocated approximately 6,445 MB (~ 6.29 GB) of memory, the OOM killer terminated our process! You now need to understand why this occurred at this particular number.
On this particular Fedora Linux VM, the RAM is 2 GB and the swap space is 2 GB; thus, the total available memory in the memory pyramid = (CPU caches +) RAM + swap.
This is 4 GB (to keep it simple, let's just ignore the fairly insignificant amount of memory within the CPU caches). But then, it begs the question, why didn't the kernel invoke...
