[Q]: Can a WM positively affect the responsiveness of a system at low-memory state?
GHNewbiee opened this issue · comments
When a system runs out of memory it becomes unresponsive for some time which may cause fatal problems.
In kernel space there are already techniques and tools (rlimit, ulimit, cgroups, swapping, OOM-killer, etc) to avoid unresponsiveness or recover the system to an operational state.
I wonder if a WM would play a proactive role to that issue and how.
For example: One way I see that may exist is to give extremely high priority to the "close" order of windows which contributes to the immediate release of used memory (is that feasible)?
Tia
Interesting thought! What would be the feature here? Would it be something like:
The WM can be configured to kill applications according to some order of priority when the CPU spikes above 90%
I am not a fun of autokilling applications because if a financial app is auto-killed and money gets lost , user will proceed to auto-self-killiing ! 😉😊
The ideal would be windows never become unresponsive in some smart way so that user can close any window any moment in dt time without delay to recover memory.
The problem exists, it's real . I have faced it many times .
Hence, let's start from the question, "is it possible theoretically and practically a window never becomes unresponsive in user-space?"
On the other hand , the idea of closing order would be a step forward .
Please pay attention that I write about window responsiveness and not application responsiveness.
The application may "freeze" but window controls never do! So, when I decide to closie a window, it sends a "close" signal with highest priority to the application or a "kill" signal. Any pending operation apart from saving eg swapping is halt and closing operation begins .
I.e. a safe memory area in user space is created which holds the window operations separate from applications ones. Something like that .
What do you think ?
Windows have 3 buttons minimize, maximize/restore and close.
What about an opfional fourth one kill as a "Skull". This button has to remain active even when the system does not respond at all.
😲😳
A kind of an "Emergency Shutdown" switch activated manually by pressing a "skull" button.
Sorry for getting back so late 😅 A bunch of traveling and a bunch of other mir/miracle related work has taken my attention lately.
However I do understand better what you mean now! The compositor does technically have the ability to force close a window (e.g. by force closing the Wayland socket). I also have run into this same problem when processes like CLion fail to close, and I usually end up having to kill -9 <pid> it to get out of that situation. There might be a better way now that you bring it up...
I also have run into this same problem when processes like CLion fail to close, and I usually end up having to kill -9 it to get out of that situation.
If system is frozen, I suspect you cannot even open a console window (terminals switch may work). Only mouse pointer is working sometimes . Hence, click on Skull button should immediately ( in the highest priority) execute the kill -9 <pid> command to release occupied memory and remove cpu load.
I would also potentially like that feature 😄 Interesting idea. I think it's a good potential "kill switch" feature. It might not manifest itself as a skull button, since many applications only want client-side decorations, but it could be a keybind of some sort that the compositor handles.
Common users are not familiar with keybinds . A lot of people use a machine ONLY through a GUI and mouse. They use only what they can see in DE at first or second sight (menu, options , etc). They hate mystical features.
Try to make the features apparent to them through GUI and one-click if possible.
Note: I use pc the last 40 years , I do only know/remember cut/copy,/paste. I have spent for configuring keybinds no more than 2-3 hours in my whole life and I have regretted it. Especially those ones which will be used once a month or 3-6 months.
IMHO , add the Skull button in API. Any app wants only client-side decorations will avoid calling it. It could also be optionally added to windows by users . Just give the freedom to the users to choose to use it or not.
It would be possible for the Skull button to automatically appear (a dynamic feature) in windows when used memory and/or cpu load reach preset values defined by user as options .
IMHO , that would be a great feature!