> But the later one is more complex and a proper > handling really depends on the particular workload That is why I advocate the introduction of new tunables. > There are workloads which prefer a temporary trashing over its working > set during a peak memory demand rather than an OOM kill OK, for such cases, the OOM handles can be set to 0. It can even be the default value. > On the other side workloads that are > latency sensitive I daresay that this is the case with most workloads. An internet server that falls into thrashing is a dead server. > no simple solution can be applied to the whole There are several solutions and they can be taken into the kernel at the same time, they all work: - min_ttl_ms + MGLRU - vm.min_filelist_kbytes-like knobs - PSI-based solutions. > For the most steady trashing situations I have > seen the userspace with mlocked memory and the code can make a forward > progress and mediate the situation. I still don't see a problem in making all the kernel-space solutions in the kernel.
