Memory Hog Basics & Impact

In this post, I will go over the basics of a memory hog and the impact/consequences of a memory hog on an embedded system.

Background - Overcommitting Memory Model in Linux

If we follow the model of running only as many applications as the available memory permits, why would we have memory hogs? However, in such conservative model, the use of physical memory is not maximized.

A process doesn't need all of it's pages to be in RAM for smooth execution. Using this information, Linux maximizes the number of processes that can be run simultaneously. So, Linux overcommits memory to more number of processes than the available physical memory permits. If processes request the more memory than available physical memory, Linux swaps out some of the RAM pages to disk (swap space) and uses these RAM pages to serve the memory request. These swapped out pages are swapped in back when needed in future. But, these pages might then be loaded at different physical locations depending on where the physical memory was available when they are swapped in. So, due to swap space, the same process could physically be at different locations at different times of it's execution.

Linus keeps processes totally agnostic to this mechanism. To achieve this transparency, linux uses virtual memory concept. Each process is given it's own virtual address space. This virtual address space is mapped to physical memory using page translation tables. This virtual memory concept also allows to keep compilation & linking of application binaries agnostic to these physical memory relocations.

Memory Hog

When an user space application or kernel module or kernel uses up excessive amounts of system memory by unusually requesting the memory overcommitted to it, it causes memory hog & deprives memory to other components in the system.

Memory Hog Consequences

A memory hog reduces the amount of memory available to the system goes down & hence can cause software:

• to perform poorly by reducing the amount of memory available in the system
• to malfunction due to memory allocation errors. Typically, memory allocator swaps out some RAM pages so that a memory allocation can be served even when there is no available physical memory. However, when the swap space is full, memory allocator fails to allocate new memory. This situation is called Out of Memory (OOM). If application's error handling wasn't properly unit tested, these errors could bring down the system too.
• to eventually bring down the entire system