4 ms·

> if a process makes your VM unresponsive, it's just about always contained to that VM. I still wonder why kernels can't just handle this properly. I've seen

> if a process makes your VM unresponsive, it's just about always contained to that VM. I still wonder why kernels can't just handle this properly. I've seen it in both Windows and Linux systems, something takes all the CPU or I/O or RAM, and the UI is so starved that you can't kill it. Shouldn't that already be handled by things like virtual memory, and the kernel scheduler? Why do modern OSes, that have to protect against such complicated attacks like Spectre, struggle to do what the very first multi-tasking kernels promised before I was born?

orblivion 5y ago
Yeah, beats me.
willcipriano 5y ago
The task manager in Windows has a higher priority than everything else if I recall correctly. Its not pure ram or cpu usage that causes you to be unable to reach it but waiting for blocking sys calls I'd suspect.
seanw444 5y ago
Isn't this what a microkernel is supposed to accomplish?
- aidenn0 5y ago
  Microkernel vs monolith has very little relation to resource (time and space) allocation, other than the fact that a microkernel is going to have an easier time with preventing runaway space usage of kernel services.
ShowalkKama 5y ago
this is what SysReq is for. >The magic SysRq key is a key combination understood by the Linux kernel, which allows the user to perform various low-level commands regardless of the system's state. It is often used to recover from freezes, or to reboot a computer without corrupting the filesystem.[1] Its effect is similar to the computer's hardware reset button (or power switch) but with many more options and much more control. https://wikipedia.org/wiki/Magic_SysRq_key?lang=en https://wikipedia.org/wiki/Magic_SysRq_key?lang=en
- codethief 5y ago
  Not really. The UI will still be unresponsive and the only thing you can do is reboot the system safely using Magic SysRq. What OP is asking about is why the UI is unresponsive in the first place.
  - lolc 5y ago
    When I ran memory-intense tests on low ram, I had the sysrq sequence for the oom-killer at my fingertips. When the system would start thrashing, it was a quick way back to safety.
aidenn0 5y ago
It's levels of abstraction. The kernel does not know that swapping out X11/window-manager/gnome-terminal/whatever will make your system unusable. There is mlockall() but it's a loaded footgun by default, and is rlimit-ed by default because it's not something you want users on a multiuser system to be able to do willy-nilly.
michaelmrose 5y ago
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.
- folmar 5y ago
  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.
- chupasaurus 5y ago
  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.

orblivion 5y ago

Yeah, beats me.

willcipriano 5y ago

The task manager in Windows has a higher priority than everything else if I recall correctly. Its not pure ram or cpu usage that causes you to be unable to reach it but waiting for blocking sys calls I'd suspect.

seanw444 5y ago

Isn't this what a microkernel is supposed to accomplish?

aidenn0 5y ago
Microkernel vs monolith has very little relation to resource (time and space) allocation, other than the fact that a microkernel is going to have an easier time with preventing runaway space usage of kernel services.

ShowalkKama 5y ago

this is what SysReq is for. >The magic SysRq key is a key combination understood by the Linux kernel, which allows the user to perform various low-level commands regardless of the system's state. It is often used to recover from freezes, or to reboot a computer without corrupting the filesystem.[1] Its effect is similar to the computer's hardware reset button (or power switch) but with many more options and much more control. https://wikipedia.org/wiki/Magic_SysRq_key?lang=en https://wikipedia.org/wiki/Magic_SysRq_key?lang=en

codethief 5y ago
Not really. The UI will still be unresponsive and the only thing you can do is reboot the system safely using Magic SysRq. What OP is asking about is why the UI is unresponsive in the first place.
- lolc 5y ago
  When I ran memory-intense tests on low ram, I had the sysrq sequence for the oom-killer at my fingertips. When the system would start thrashing, it was a quick way back to safety.

aidenn0 5y ago

It's levels of abstraction. The kernel does not know that swapping out X11/window-manager/gnome-terminal/whatever will make your system unusable. There is mlockall() but it's a loaded footgun by default, and is rlimit-ed by default because it's not something you want users on a multiuser system to be able to do willy-nilly.

michaelmrose 5y ago

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.

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