6 ms·

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

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. However, the user experiences the PC freeze during certain conditions, however you choose to name them, and it is during that freeze period the user needs a program to be killed to free some memory and prevent the freeze. I would take one crashed program over power cycling the entire PC any day of the week.

rnhmjoj 5y ago
> 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 5y ago
  >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 5y ago
    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.

rnhmjoj 5y ago

> 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 5y ago
>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 5y ago
  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.