[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)