On Mon, Jan 6, 2020 at 10:28 PM Mark Otaris <mark(a)net-c.com> 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@dread.disast...
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