The document discusses the algorithms of the Linux memory manager, highlighting the watermark mechanism and its drawbacks, such as the need for near full memory to initiate reclamation and potential I/O pressure. It also addresses the swappiness variable and its ambiguity, along with how the Out Of Memory (OOM) mechanism may inadvertently terminate critical processes due to poor tuning options. Lastly, it introduces reverse mapping (rmap) as a method for accumulating hardware reference counts of memory pages.

1. Algorithms of Linux Memory
Manager (Simplified)
L J GOKUL VASAN

2. Watermark Working In Linux
Detriment:
•Statically defined.
•Almost, whole memory needs to be filled to start reclamation.
•Could cause I/O pressure.
•Reclamation could cause false positives, leading to thrashing.
• Trigger’s page replacement.
• Defines aggression of the
replacement policy.
• Are per zone free list's waypoint.
• Represented as count of free
pages.

3. Swappiness variable in Linux scan rate
• Detriment:
❑Ambiguity in semantics of variable.
❑Global variable that effects the whole node.

4. OOM in Linux
• Kills the process with highest
OOM badness.
• Detriment:
❑oom_score_adj :
❑Admin or system developer has little
or no clue on tuning this variable per
process.
❑Might kill a process that’s of
importance to system.
❑Does not provide right statistics for
developer’s debugging.

5. RMAP [Reverse Mapping]
• Opposite to Memory Mapping.
• Traverses the PTE of a page and cumulates hardware
reference count.