Welcome to the Linux Foundation Forum!

memory scheduler

a1b2c3d4e5
a1b2c3d4e5 Posts: 5
in Kernel Development

Why does the Linux kernel lack a centralized memory scheduler?
How can the kernel objectively and fairly allocate a limited physical resource like RAM among competing processes and containers without a unified, proactive mechanism that decides in real time who gets how much memory?
Doesn't this mean that Linux effectively manages one of the most critical and scarce hardware resources (DRAM) in a purely reactive and opportunistic way — basically "first page-fault, first served"?

Or is the current reactive model (page faults → direct reclaim → kswapd → LRU → OOM killer) somehow considered "good enough" in 2026?

Answers

  • a1b2c3d4e5
    a1b2c3d4e5 Posts: 5
    edited 4:26AM

    "An important point: the Linux kernel doesn't have a mechanism that intelligently and proactively allocates physical memory to processes or containers—that is, it doesn't decide in advance and fairly: 'This process is entitled to 4 GB, that one to 2 GB, and this cgroup to no more than 1 GB.'

    Instead, the kernel does the following:

    It allocates memory almost on a page fault-first basis (reactively, on demand).
    However, it's very good at reclaiming memory when it runs out: kswapd, direct reclaim, memcg reclaim, compaction, proactive reclaim (DAMON), PSI-driven reclaim, and, in extreme cases, OOM killer.
    It turns out that Linux doesn't allocate RAM intelligently and predictably, but only reactively reclaims it from those that aren't prioritized by LRU or other heuristics.

    "Can't allocate smartly. Can reclaim ruthlessly."

Categories

Upcoming Training