[rnhmjoj]

> I am sure that this distinction between a near-OOM condition and an actual OOM condition matters to someone familiar with the current kernel implementation. You seem confident describing what happens when the memory gets closer to full, so I believe you.

I'm not a kernel developer or anything like that, I've just spent some time investigating why this issue happens and has been happening for more than 10 years now.

> the user experiences the PC freeze during certain conditions, however you choose to name them

I'm not trying to defent the Linux kernel, I just described how it works. In particular it's not true that the OOM killer "takes too long" or doesn't work: it's just not invoked at all. If you invoke it manually (enable the magic SysRq with`sysctl kernel.sysrq=1` and press `alt-sysrq-f`) it does its job and solves the OOM instantly.

So, if you don't want to deal lockups and don't like an OOM userspace daemon (I don't), these are the possible solutions.

> I would take one crashed program over power cycling the entire PC any day of the week.

On a laptop or desktop PC, you don't need to power cycle in a near-OOM: use the magic SysRq key.

[hollerith]

>On a laptop or desktop PC, you don't need to power cycle in a near-OOM: use the magic SysRq key.

Thanks for the tip! If my Linux were ever to start locking up regularly, I will apply it.

But right now (so I don't have to give up the use to which I currently put my SysRq key) I would prefer some method for determining after I forcefully powered down the computer, then powered up again, whether the lockup or slow-down that motivated the force-power-down was caused by a near-OOM condition.

Do you happen to have a tip for that?

[rnhmjoj]

I don't think so, sorry. The kernel emits a few messages when an OOM is detected, including the tasks killed to free memory, but in a near-OOM probably nothing: the system is technically still working normally, though very slowly.