No announcement yet.

Ubuntu 22.04.1 LTS Preparing For Release With Retbleed Patched, Intel AMX, Other Fixes

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by plinkyplonky View Post
    Does this release fix the issue with randomly closing down Firefox or Chrome because it used RAM?
    It wasn't random. It happened when ram use triggered thresholds in the new systemd oom killer. However, ubuntu has changed the parameters to basically give up on the systemd oom killer for the moment. In my testing, it basically doesn't do anything any longer. It will only kill if memory pressure on user apps is sustained at 50% for ten seconds, and in my testing, that is virtually impossible. My CPU load average will go above 50 (system crawls) with the user slice memory pressure is still under 20%. If you have a 4GB ubuntu machine, I think you need to do tuning to get it working well. Out of the box Ubuntu is not very good. I think they were banking on systemd oomd to be the white knight, but it has not turned out like that, yet.

    systemd oomd is very hard to tune correctly. There is a small range of values where to the "left", it kills too quickly and to the "right" it doesn't do anything, as far as I can see. Very hard to find the sweet spot. I am not optimistic about it. However, Fedora has the same problems, and both distributions are trying to fix things. Ubuntu says upstream is working on rules to indicate that some user apps should be protected from being the first candidates to be killed, in which case over enthusiastic killing won't be such a problem, although working out what to protect in a way that everyone agrees may not be so easy. For sure, the gnome shell should be protected, but do you protect Firefox or vscode or what next?
    The big problem that whatever it does it's like a lightning bolt for Zeus (no warning) seems not to have any solutions being proposed yet.

    Meanwhile, the next version of systemd will allow memory pressure to be calculated not over the entire user slice, but for individual apps, which might make it a more useful measure (system slices only have a few processes, the user slice can have >1000 processes).

    The other interesting point is that MGLRU, the much better page swapping algorithm, has a pretty dramatic benefit in low memory situations. Compressed ram swap (zswap) works better and the kernel OOM killer is much better in desktop situations. It kills processes without knowing what they are, although of course it has algorithms to choose. People use to complain that the kernel oom killer was so stupid that it might kill the login session; in fact, this is one of the problems with the systemd oom killer. In my testing, with xanmod, if I cause huge memory stress by loading lots of browser pages, if the systemd killer gets it right mos tof the time;, it detects that the browser is the problem and then kills the entire browser with all the tabs, whereas the kernel killer will kill processes, which means individual tabs (the kernel kills also gets it right most of the time, at least with xanmod). Once it has killed enough tabs, it stops. So you don't lose the entire browser. I think that's better. It is slower to react, but the old days of the system live locking for a long, long time seem not to happen (I tested with 4gb ram, 2 to 4gb of zswap, two cores).

    A userspace killer like systemd oomd should be better, but so far, not so.

    But I don't hear a thing about MGLRU and the upcoming 6.0 kernel. You can try it in the xanmod kernel.
    Last edited by timrichardson; 03 August 2022, 05:51 PM.


    • #12
      Originally posted by timrichardson View Post
      It will only kill if memory pressure on user apps is sustained at 50% for ten seconds, and in my testing, that is virtually impossible. My CPU load average will go above 50 (system crawls) with the user slice memory pressure is still under 20%.
      I realise my use-case is extremely specific, but I can maintain 97-100% CPU load with 1.45TB of 1.5TB of RAM utilised by a single process for upwards of a week on certain datasets. Admittedly that particularly scenario is rare (~700GB is quite common, however) but I prefer Ubuntu/Debian/(Arch)/(Gentoo) to RedHat for historical reasons (RHEL/CentOS kernel panicking on boot on Supermicro quad-socket G34 boards, others not having a problem) so I have been watching the oomd furore with more acute interest than normal. Easy enough to disable, I know, but the manifest issues with even simple scenarios had me preparing to add disabling oomd to my prep scripts.

      The xanmod information is interesting, thanks.


      • #13
        I miss the port of Doom that some masochist made a long time ago, where each bad guy you kill corresponds with a random process id on your system. I don't care who you are, that's a fun one to play.