Linux Oom-killer

I am engaged in the development of UTM, recently encountered out of memory killer. Here's a little bit of information.

Briefly

When system memory is low, the system triggers Oom-killer.
Oom-killer mechanism is to choose to kill the most suitable process, free memory, increase the system's available memory.

When does the Oom-killer trigger?

Trigger Oom-killer is not allocated memory in malloc, but when virtual memory is mapped to a physical address when the allocated memory is actually used.
A description of the manual in malloc

By default, Linux follows an optimistic memory allocation
Strategy. This means if malloc () returns Non-null
There is no guarantee, the memory really is available.
This was a really bad bug. In case it turns out that the sys‐
TEM is out of memory, one or more processes'll be killed by
The infamous OOM killer. In case Linux is employed under cir‐
Cumstances where it would is less desirable to suddenly lose
Some randomly picked processes, and moreover the kernel ver‐
Sion is sufficiently recent, one can switch off this overcom‐
mitting behavior using a command like:
# echo 2 >/proc/sys/vm/overcommit_memory

Overcommit is a memory usage mechanism for Linux. With /proc/sys/vm/overcommit_memory configuration, there are three types of values:

overcommit_memory	Description	Comment
0	Heuristic strategy	Reject significantly too large memory allocations. For typical systems. Root can allocate more memory than the average user.
1	Allow Overcommit	This strategy is suitable for applications that cannot withstand memory allocation failures, such as scientific computing.
2	Prohibit Overcommit	The total memory usage space must not exceed the swap+ram* factor. When malloc is not running out of memory, it returns an error. The coefficients can be configured by /proc/sys/vm/overcommit_ratio , which defaults to 50.

As long as there is overcomit mechanism, the memory is not enough, it is bound to trigger oom-killer.

Why use Oom-killer?

The kernel of most major distributions sets /proc/sys/vm/overcommit_memory to 0, which means that the process can request more memory than is actually available. This is a heuristic policy based on allocated memory and not necessarily immediately used, and it is possible that the process does not fully use all of the memory it allocates during its entire run.
If Overcommit is forbidden, the system will not be able to fully use all of the memory, thus wasting a portion.
Overcommit allows the system to use memory in a more efficient manner, but with the risk of oom.
A greedy process that consumes memory may drain the system's memory and cause the system to stall.
This leads to a situation where the memory is low and even a page is not enough to allow the administrator to kill the appropriate process, allowing the kernel to take some important actions such as freeing up memory. In this case, the Oom-killer chooses and kills the appropriate process for the rest of the system's tasks to consider.

How does the processing mechanism of Oom-killer choose the most suitable process?

Select the most appropriate process through a scoring mechanism (Badness score). Badness score through/proc/<pid>/oom_score embodiment.
The principle is to change the maximum memory with minimal loss.
Badness score is related to the memory that the process consumes, its CPU time, the run time, its/proc/<pid>/oom_adj, the run level nice.
The more memory consumed, the shorter the run time, the higher the badness score.
Conversely, the less memory consumed, the longer the run time, the lower the badness score.
If the badness process is the parent process, it and its child processes will be killed.
The specific implementation of the reference kernel oom_kill.c in the badness () function.

Reference Links:
Taming the OOM Killer
When Linux Runs out of Memory
How the Linux OOM killer works

Linux Oom-killer