Implement a recovery virtual console for a hanged system

This might be a duplicate of "[reserve memory for a set of processes](https://unix.stackexchange.com/questions/401769/reserve-memory-for-a-set-of-processes) ", but I think my question is a little broader. I have a system that likes to hang a lot. I tend to use a lot of browser tabs and a bunch of Electron apps; sometimes when too many of these are open my system comes to a complete stop. Usually my solution is to just Alt+SysRq+F to forcefully invoke oom_kill, this usually results in my browser getting killed. I have been meaning to install a user-space service killer for a while so that I get a more proactive prevention of a system freeze, but honestly, it wouldn't change much (unless I was doing something time sensitive and couldn't afford a 2.5s before oom_kill is complete). I would much rather the ability to choose what I want to be killed. To that end, I would like to have a "holy virtual terminal", one that I can simply Ctrl+Alt+F1 (my graphical session lives in Ctrl+Alt+F2) and then use either top or btop to kill whatever I want to restore my system to a working state. I want a guarantee that it _will have enough memory/cpu priority to function_. Right now if the hang is bad enough, it either takes minutes for a login prompt to show up on virtual consoles, or the login itself times out after 60 seconds. Is this possible? How? Would "niceness" be relevant? Perhaps there is a kernel module for it? I wouldn't mind permanently losing 1GB or less of memory in my system if that was necessary (if it needed to be "allocated" to such a console). Previously I thought one of the solutions would be to create a default cgroup that would only allow up to System Ram - 1Gb, then I could somehow have tty1 be on a different cgroup which wouldn't have that memory limit. I don't really know how that would be achieved, but it sounds possible. However, there seems kernel parameter that was designed specifically for this purpose: [vm.admin_reserve_kbytes](https://www.kernel.org/doc/Documentation/sysctl/vm.txt) > The amount of free memory in the system that should be reserved for users with the capability cap_sys_admin. > > admin_reserve_kbytes defaults to min(3% of free pages, 8MB) > > That should provide enough for the admin to log in and kill a process, if necessary, under the default overcommit 'guess' mode. My system is already in 'guess' mode, but if I can't even get a login prompt, I don't really see the point of reserving for root if you don't have enough memory to login as root. It sounds like some combinations of these parameters would allow me to get what I want, but it isn't clear to me right now what that would be.