Announcement

Collapse
No announcement yet.

Ubuntu Developers Have An Idea For Handling The Over-Eager Systemd OOMD App Killing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oibaf
    replied
    1. Zram helps a lot.
    2. ‚Äč‚Äčnohang is an alternative, can kill single browser tabs rather than the whole browser.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by NotMine999 View Post
    Yes, I agree. Newbie computer users should not run Linux.

    They should stick to MacOS...or better yet...Windozes
    Huh? I didn't expect that to be the reading of my post, but I guess it's a valid one. I'll clarify: Canonical, most likely, made a lousy default. Noobs should have a decent experience. But that means defaults need to be sane configurations. One that kills the users' browsers when there's no memory pressure is not it.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by sarmad View Post
    Why not, aren't we currently allowing a systemd/Canonical engineer to kill anyone's process? Might as well allow someone actually authorized to access the machine.
    A privileged service, not just any user. It's, for a start, an actor you trust just as much as your kernel to do the task.

    Originally posted by sarmad View Post
    Aren't we currently simply hoping an admin will say "hey I'm bored let's check if any of my processes have been killed"?
    If you manage any server, and I do not want to know, I expect you have some kind of heartbeat running. And, further, I expect you configured vital services to restart on their own if they die.

    Originally posted by ssokolow View Post
    What, specifically, are you referring to as the "let it sit" case?
    It was suggested that if the user wasn't around or it was a server, the thing just waited and waited.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by sinepgib View Post
    For those screaming "just buy more RAM": ugh. It's tiresome to read the same dumb crap again and again.

    WRT the actual problem, it seems to me it's poorly configured...
    Yes, I agree. Newbie computer users should not run Linux.

    They should stick to MacOS...or better yet...Windozes

    Leave a comment:


  • NotMine999
    replied
    Originally posted by CochainComplex View Post
    What ever Idea it is ....it will be implemented by using snap.
    And when it kills your favorite app...OH SNAP!!

    Leave a comment:


  • ssokolow
    replied
    Originally posted by sinepgib View Post

    Fair enough, I thought it was meant as a replacement for the eager reclaiming. What happens in the "let it sit" case, tho?
    What, specifically, are you referring to as the "let it sit" case?

    Leave a comment:


  • sarmad
    replied
    Originally posted by sinepgib View Post
    What happens if the user isn't the criminal? Is the user allowed to kill anyone's process?
    Why not, aren't we currently allowing a systemd/Canonical engineer to kill anyone's process? Might as well allow someone actually authorized to access the machine.

    Originally posted by sinepgib View Post
    No notification. Simply hope an admin will say "hey I'm bored let's check if we have OOM". And no, no way to notify either, until there's enough memory the system is pretty much halted.
    Aren't we currently simply hoping an admin will say "hey I'm bored let's check if any of my processes have been killed"?

    Leave a comment:


  • sinepgib
    replied
    Originally posted by remenic View Post
    This sounds like a group of students trying to find a solution to a problem that should have been solved a decade ago, and I honestly can't imagine it isn't. How come this affects Linux so much?
    All problems are trivial when you are not in charge of solving them

    Leave a comment:


  • binarybanana
    replied
    Originally posted by AndyChow View Post
    Pfff, n00bs. Just get a faster internet connection and download more RAM.
    You joke, but Linux supports swap files over nfs, so technically this is indeed possible. if that swap file were on a ramdisk/zram or fast NVMe on the other end it might even be useable. Never tested it, though.

    Originally posted by skeevy420 View Post

    I have 32GB of ram and OOMD killed Firefox yesterday. I had a few GB sized archives open, FF+10 tabs, 3 Dolphin tabs, Gwenview, KCalc, and Kate. During that I started backing up some files to a Zstd-19 compressed directory where ZFS ballooned its memory usage and instead of ZFS giving its memory back like ZFS normally does, OOMD decided to kill Firefox.

    That was the first time that OOMD killed a running process on my system. Pissed me right off.



    There is one. I don't know if the blame is OpenZFS or OOMD, but there is a problem. ZFS is supposed to give up memory when other programs request it. OOMD kills shit faster than ZFS can make that decision. Instead of ZFS going "Whoops, my bad, didn't mean to be so greedy. Here's some ram." Firefox gets killed.
    Problem is zfs on Linux doesn't integrate with the normal page cache. It uses its own cache pool. While it should be able to adjust dynamically it might not be hooked up in all the relevant code paths in the same way as the regular page cache. Maybe it even just periodically frees some memory if memory pressure exceeds some value. i don't know exactly what it does, maybe it's smarter than this worst-case but it'll probably never work as well as in-tree file systems without major rework which would hurt portability.

    Leave a comment:


  • remenic
    replied
    This sounds like a group of students trying to find a solution to a problem that should have been solved a decade ago, and I honestly can't imagine it isn't. How come this affects Linux so much?

    Leave a comment:

Working...
X