On Fri, Apr 15, 2022 at 11:03:07AM +0100, piorunz wrote:
> On 15/04/2022 06:53, tomas@tuxteam.de wrote:
> > If you want to learn more about that, the Linux MM ("memory
> > management") people have set up a wiki for that:
> >
> > https://linux-mm.org/OOM_Killer
> >
> > Enjoy:)
> >
> > (and yes, on my box, more memory-hungry processes have a higher
> > /proc/<pid>/oom_score, so they seem to incur a higher risk of
> > being killed. The browser lies somewhat because it spawns quite
> > a few processes, but as a product of the propaganda industry,
> > lying is its second nature;-)
>
> Yes I understand that from my point of view everything is bad and I am
> not objective.
> However, I see how things are broken and that is indeed obvious.
> I seen before my own eyes how Linux killed KDE session including Xorg
> but left 10x wine's exe processes with 8GB RAM each as a last. Entire
> tree with parent process was using all of the memory that would be 50+
> GB. How this process tree is not having HIGHEST POSSIBLE OOM score and
> is not being killed in first microsecond of OOM situation is beyond my
> understanding.
- At the "low level": you are talking about "process trees".
Perhaps that's the problem. Perhaps, towards the OOM score,
all those processes count as individual processes. Note that
the OOM killer is just the last straw the system grabs to
try to avoid sinking. Perhaps it's the wrong instrument for
your case and you need to look into limits, or cgroup memory
policies.
- At the "higher level": "you see how things are broken" for
you. You are still (in my opinion) committing the error of
generalising your problem /before/ you have spent enough
time investigating it. That might make it more difficult
finding a satisfying solution :-) Plus, don't assume random
kernel programmers aren't smart. They usually are. And they
usually spend quite a bit of effort until a patch of this
kind goes in.
Cheers
--
t
Attachment:
signature.asc
Description: PGP signature