zlacker

[parent] [thread] 2 comments
1. michae+(OP)[view] [source] 2022-03-23 17:00:45
Windows has a single official UI and a low level handling of a key press to bring up an element that must ideally remain responsive.

Linux has many and a set of low level responses to keybondings that must remain responsive that don't have a UI nor ability to kill individual applications.

To be fair in current systems Linux UIs normally remain responsive until memory exhaustion which is handled very badly. You will probably reboot before the oom killer assassinates the offender. The fix is a user space daemon like earlyoom which activates at a configurable level and targeting rather than absolute exhaustion when even killing the offender is challenging and usage has been hard for tens of minutes.

You or your environment can also set your UI process to a higher priority as far as processing and io.

If your UI doesn't remain responsive it's because your distro isn't using existing tools to achieve this.

replies(2): >>folmar+5s >>chupas+Pt
2. folmar+5s[view] [source] 2022-03-23 19:34:49
>>michae+(OP)
If you are at the physiacl keyboard you can run the oom killer via the sysrq key. I would say that the kernel oom killer is quite usable since the last few years but is triggered too late - especially for applications like Firefox that handle malloc failures gracefully.
3. chupas+Pt[view] [source] 2022-03-23 19:44:12
>>michae+(OP)
oomkiller wouldn't help if there's an I/O overload (good old friend Linux kernel bug #12309) since memory usage is fine, just your system can't read anything from network or storage.
[go to top]