On Fri, Apr 15, 2022 at 02:09:04AM +0100, piorunz wrote:
> On 01/04/2022 07:08, tomas@tuxteam.de wrote:
[...]
> > See man (1) choom and search for oom in man (5) proc.
> Thanks! That's exactly what I needed. Amazing.
You're welcome :)
> Now, after I start the process, I run:
>
> Adjust to maximum setting (kills first):
> choom -p `pidof terminal64.exe` --adjust 1000
>
> Lower priority of a processes:
> renice 19 `pidof terminal64.exe`
>
> That way offending process will never hang or destabilize my system.
>
> I just wish that Linux kernel would give maximum oom score to process
> with most memory, that's so obvious!
To a certain extent, it does (see below).
> But instead, defaults are so bad,
> it kills everything but one offending process.
> Can this be reported as a bug against linux kernel in Debian bug track?
You can, of course, try. Your chances of success would be better
if you tried to understand what kind thoughts have gone into it,
and why it's not working for you. The way you are putting it, it
comes across (to me, at least!) as "what kind of stupid design
is this" (cf. your words: "obvious", "defaults so bad"). I know
you don't intend that, but, as you can imagine, it won't fly if
that's how others perceive it :-)
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 ;-)
Cheers
--
t
Attachment:
signature.asc
Description: PGP signature