Pages will not stay in the active LRU if the accessor is stalled.

Edit: You keep repeating that all over the thread - i started my week an hour ago and i had two of these memory stall events during the weekend. Again its the machines with big binaries running and no swap. Maybe you could provide a better explanation than "this doesn't happen"?

You keep repeating that the program text pages are being evicted as if that were the only thing that happens under memory pressure. It is the last thing that happens after the kernel drops all regular page cache, causing I/O starvation, and without swap, the kernel can't do anything about inactive anon pages. This means that at this moment, you are almost out of memory and the kernel can't do anything other than shuffle the remaining pages, thrashing the I/O. The kernel can't predict the future and doesn't know if it is a temporary situation due to some load spike or if it is a memory leak and resources won't be available again. The kernel doesn't know SLOs and operator priorities - whether the workload should survive at all costs, or the stalls are not acceptable and the workload should be OOM-killed. It is the job of the operator to give the kernel appropriate information by setting cgroup limits and monitoring memory pressure. If you want the workload to be OOM-killed before it consumes all the memory and starts causing I/O thrashing - set `memory.max` and `memory.swap.max` cgroup limits. If you want the workload memory not to be reclaimed by the kernel - set `memory.min`.