[HN Gopher] Hastening Linux process cleanup with process_mrelease ___________________________________________________________________ Hastening Linux process cleanup with process_mrelease Author : chmaynard Score : 42 points Date : 2021-07-26 19:48 UTC (3 hours ago) (HTM) web link (lwn.net) (TXT) w3m dump (lwn.net) | rbanffy wrote: | A possible solution not to this, but for the OOM killer would be | an "importance" attribute orthogonal to the task priority - it's | ok to kill the NTP server or to bounce the DNS proxy. It's much | less OK to kill Emacs or my desktop. | calpaterson wrote: | > That work did not address one other unfortunate characteristic | of the OOM killer, though: its opinion of what is the least | important process on the system tends to differ from that of the | system's users. | | My experience of the linux OOM killer is not that its opinion | differs from mine but that it has no opinion at all for a long, | long time after the system is in deep trouble. The OOM killer | simply does not act quickly enough to save systems. Sadly it's | not customisable but 'earlyoom' (packaged for debian and probably | everything else) is. I turned it on when I was messing about when | debugging a badly behaved bit of software which went into a | memory allocation loop and have just left it on. It's saved me a | few times and I now plan to leave it on forever. | | Looks like oomd is an idea along the same lines but with slightly | different goals. It's not in my distro so not an easy option for | me. | GranPC wrote: | I used to experience this a long time ago, and I know many | people who still do - but on my system (running an Ubuntu 18.04 | derived distribution) the OOM killer takes at most 3-4 seconds | to step in and kill whichever process is consuming the most | memory. Does anyone know if Ubuntu/Debian tunes the OOM killer | differently to try and stop this from happening? | freedomben wrote: | This is my experience also. By the time the OOM killer kicks | in, the system has been locked for 15 to 20 minutes already. If | it was production you've already terminated the instance. If | it's your laptop or desktop, you've already held the power | button. | | Fedora has earlyoom enabled by default but so far it hasn't | saved me. I really need to look into configuring it. How did | you get started? Man pages? Blog post? | cmurf wrote: | earlyoom is enable on Fedora 32 and 33 Workstation edition; | and 33 KDE spin. On Fedora 34, all editions and spins have | systemd-oomd enabled. It does take some initial configuration | of systemd service units since oomd works by cgroupsv2 based | accounting and killing of entire cgroups, not PIDs. This work | is still a work in progress, with uresourced setting up the | initial resource allocations (with planned obsolescence). It | should be safe to run uresourced on any edition or spin but | right now it's only enabled by default on Workstation | edition. | | If the results you're getting aren't expected, there's still | some chance it's a bug somewhere, so you should report it | against systemd, attach `journalctl -b -o short-monotonic | --no-hostname` or at least ~10 minutes of logging prior to | the unexpected behavior you're reporting. | teddyh wrote: | This seems useful for systemd when stopping services. ___________________________________________________________________ (page generated 2021-07-26 23:00 UTC)