71–80 of 103 posts
Earlier quoted context omitted.
I'm aware of it, but it's awkward to use in practice. You have to track down all the FF processes, each time you run it, and adjust all their scores.
Maybe firefox could self-adjust, as a policy?
I should really send a patch rather than complaining ...
It's a funny reply. But what was not funny was the OOM killer killing my screen locker.
Joke all you want, but 22 years later I still stand by that I'd rather get a kernel panic than kill the screen lock.
These days you can do oom score adjusting, which is not as strong as a pardon. I may be taking too much credit, and may misremember the timeline, but I feel like someone took my crappy kernel patch and went "fine, I'll do it the right way", merged that oom score adjusting maybe a year or so later.
Here's an LWN article about it, too: https://lwn.net/Articles/104179/
It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
It would be nice to have a signal as a warning to process to reduce it's memory footprint or else OOM will kill it.
cgroups v1 has a pretty nice API but it requires root. V2 does not require root but it’s a lot coarser and not as simple or reliable: https://unix.stackexchange.com/questions/753929/receive-a-me...
It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
It would be nice to have a signal as a warning to process to reduce it's memory footprint or else OOM will kill it.
Earlier quoted context omitted.
because this is what causes Windows to use ~80% more memory than unixes
Well, in that case it's a good thing I guess. Windows is orders of magnitude better when it comes to memory management on the desktop compared to Linux. Like why would I even want a single process killed by OOM killer? On Windows things just work, or get slow. On Linux it works and then mayhem ensues. Last year I was writing a reply on a forum in Firefox on Linux when the OOM killer decided to nuke Firefox. Poof gone…
The bar is pretty low, but the windows scheduler is aware what the currently focussed app is so it can prioritise not killing it.
On Linux? Not so much.
Hey, that's me! (suggesting an OOM pardon feature) It's a funny reply. But what was not funny was the OOM killer killing my screen locker. Joke all you want, but 22 years later I still stand by that I'd rather get a kernel panic than kill the screen lock. These days you can do oom score adjusting, which is not as strong as a pardon. I may be taking too much credit, and may misremember the timeline, but I feel like so…
An argument can be made that the kernel should not cover for architectural missteps of the X server and that X server should be the one to crash when it's security-critical component was killed for whatever reason.
I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity. There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?
I think part of it is that the design of screen lockers on X11 is just broken. If the locker crashes (or is killed), then the screen unlocks. Security-wise, it fails open. On Windows and macOS (and Wayland, using the ext-screen-lock protocol, coupled with sane compositor policy), that can't happen. The right way for this to work is for the X server to have an extension that lets a screen locker say "hey, I'm locking…
It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
It would be nice to have a signal as a warning to process to reduce it's memory footprint or else OOM will kill it.
Earlier quoted context omitted.
Well, in that case it's a good thing I guess. Windows is orders of magnitude better when it comes to memory management on the desktop compared to Linux. Like why would I even want a single process killed by OOM killer? On Windows things just work, or get slow. On Linux it works and then mayhem ensues. Last year I was writing a reply on a forum in Firefox on Linux when the OOM killer decided to nuke Firefox. Poof gone…
> Windows is orders of magnitude better when it comes to memory management on the desktop compared to Linux. The bar is pretty low, but the windows scheduler is aware what the currently focussed app is so it can prioritise not killing it. On Linux? Not so much.