On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris <mark@xxxxxxxxx> wrote: > > > 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. https://lore.kernel.org/linux-fsdevel/20200104090955.GF23195@xxxxxxxxxxxxxxxxxxx/T/#m8b25fd42501d780d8053fc7aa9f4e3a28a19c49f >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. OK. > > 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. a. Not everything is running or will run in a container; b. To what degree cgroups and PSI, making no other changes, solves/avoids the problem under discussion is workload dependent. That's stated in the last part of the email response I reference above. Of course, Fedora Workstation is a general purpose operating system. It's untenable to have workload specific operating systems. By what mechanism is the workload categorized? And by what mechanism is the system dynamical (re)configured? > 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' When I ask the question "can it be done" I'm asking for cake and eating it too. I'm not asking for an example of running something that doesn't implode the system, I know about that. I want to compile something, and have the system figure out the resources it can give to that task, without killing it, and without impacting the responsivity of my computer. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx