> For now, kernel developers have made it clear they do not care about > user space responsiveness. At all. Their concern with kernel > oom-killer is strictly with keeping the kernel functioning.
This is false. The stated purpose of the OOM killer is not only to keep the kernel alive. Nor does the fact the kernel has not solved userspace responsiveness yet imply that kernel folks do not care. Rather, it means that they will not solve it on their own because the kernel does not have all the information it needs. Kernel folks do care, or we wouldn’t have PSI or cgroups. A userspace solution is needed, but does not need to replace the OOM killer; cgroups are also a userspace solution. If earlyoom breaks them, it can make things worse than the status quo. > Can it be done with cgroupv2 and PSI alone? Unclear. Of course it can. Just run 100 instances of every stress-ng memory worker in a podman container with a cgroup memory limit. The system will not hang. Do the same without the memory limit. The system will hang within seconds and never recover. Thus demonstrating that cgroups work and do the things they were intended to do. Try it. With a memory limit, podman run --rm -it --memory=1G fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' will use CPU but keep your system responsive. Without the memory limit (this will hang your system), podman run --rm -it fedora bash -c 'dnf install -y stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100' the system hangs and doesn’t recover after 15 minutes. Same thing with `tail /dev/zero`: podman run --rm -it --memory=1G fedora tail /dev/zero activates the OOM killer after three seconds, with kernel: Memory cgroup out of memory: Killed process 8814 (tail) total-vm:3141408kB, anon-rss:1042028kB, file-rss:4kB, shmem-rss:0kB, UID:1000 pgtables:6336512kB oom_score_adj:0 systemd[943]: libpod-e061e1cb57dde204632531a556d37efbd51c9ab67346a8bc4d5e26c7301c165b.scope: A process of this unit has been killed by the OOM killer.kernel: oom_reaper: reaped process 8814 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB logged in the system journal. You were saying the OOM killer activates too late and rarely kills the right process? Well, here it activates early enough and knows exactly what to stop. It is worth trying with ninja and WebKit too. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
