Systemd-OOMD Continues Coming Together For Better Linux Out-Of-Memory Handling

[tuxd3v]

what makes you think it doesn't do that?
(...)

I believe I expressed myself wrong..
Caches should be dropped, *before* you run oom...
It doesn't make sense continuing to have cache, if memory free pool are empty..

It doesn't mean all cache needs..
Linux always had a severe problem with memory management, it starts caching and caching until you are oom or freeze..

If you have tons of memory, thekswapd processes will alleviate the problem" and *maybe* the real problem never appear,
But if your system doesn't have tons of memory.. there are a big possibility that the problem will show up and freeze your computer..or if OOM is configured, starting killing processes..

There are no sysctl control to say:
Look, I will give you 2GB of cache.. nothing more nothing less, and only on memory starvation the system would drop the caches.. like in the 2.4 Series..

I hope that this time I have expressed myself in a clear way?!

[RomuloP]

OOM killer never worked in sensible time, it made me lose time, life, money, etc... Be it because the system freeze or because I need to care about RAM limit... I've installed earlyoom and life is great again... My faith on computers being used to help humans was restored.

[polarathene]

Even a 10 years old laptop sitting right here has a SysRq feature -->> the [Fn]-End key

IIRC some distros will have the functionality disabled by default though, so it's only useful if you know about it prior and enabled it.

Here's proof of that:
https://wiki.archlinux.org/index.php...ortcuts#Kernel

Most users that learn about it would have already experienced the problem prior or trying to find a way to recover without having to do a hard reset.

[slowee]

I agree. Most users simply overload their systems. I got a web browser? KEWL! I can haz a bizillion tabs open at once. It does Steam? KEWL! I can bez in so many tournaments at once. It gotz a music player too? KEWL! And what about a few chat programs and terminal connections and a few work appz running all the time cuz I can never find'em & load'em fast enough from my personally customized menu that has really RAD KEWL colorz.

I think it is interesting that most of the whiners are not providing any details of what they are doing when they have to resort to such drastic measures. That is why I am suspect of all of the complaining that I hear in these forums, Slashdot, and elsewhere. Whiners gonna whine cuz they got nothing else to do.

I don't agree - be more specific ; what are the "users" you're talking about ?
Probably it is worth noting that many of the "most users" are kids and persons who don't know mouch about computer technology, not to mention facts like caching or swaping or overcommiting of memory.
They know "internet", "movie", "music", "game" and all of them at the same time (multitasking, you know).

Given that Linux based Desktop wants to target this user group, it needs reliable and standardized mechanism to recover from situations like OOM _without_ reset/reboot the whole system.

[AH88]

... it is worth noting that many of the "most users" are kids and persons who don't know mouch about computer technology ...

"Won't someone think of muh non-technical users!!!"

[stefansaraev]

From what I remember, Xorg takes over keyboard processing when it's got control, so the keypress to switch from console to X is processed by the kernel, but the keypress to switch from X to console is processed by Xorg. Thus, if your system is thrashing, and that thrashing is keeping /usr/bin/X from updating the screen effectively, it's also keeping it from reacting to Ctrl+Alt+F# effectively.

Xorg can not take control over input from kernel. so SysRq always works just fine, in Xorg as well.

just saying.

[ssokolow]

Xorg can not take control over input from kernel. so SysRq always works just fine, in Xorg as well.

just saying.

What I mean is that Xorg does the kernel-level equivalent of XGrabKeyboard... SysRq is just exempt from that. (That's the whole point of SysRq. To be the input equivalent of a non-maskable interrupt.)

(That's also how things like g15daemon work, so things don't see input events twice when it's necessary to remap an input and re-inject it using the uinput API for userspace input devices.)

In fact, that's where the R in Alt+SysRq+REISUB comes in:

Alt+SysRq+r Unraw

Take control of keyboard back from X.

[Danielsan]

Upgrade from 500mb of RAM and maybe you won't run out of memory so often.

There a lot of virtual servers on the cloud that for, money reasons, run at very minimum requirements and this improvement can help this situation a lot.

[RomuloP]

There a lot of virtual servers on the cloud that for, money reasons, run at very minimum requirements and this improvement can help this situation a lot.

Simply put, there is people out there just doing work where saving time is more valuable than doing memory management or avoiding exporadic data loss, like in exploratory data analysis. It is just great when the system kill the offensive process and life continue.

[abott]

The replies treating me like an idiot are laughable. I develop software in assembly, to web stuff, to even poking into kernel and user space stuff. I know how the system works, top to bottom. And I can say with confidence that the Linux kernel sucks at low memory situations. The fact you say it can't be handled in-kernel, when it's a kernel issue, shows how moronic you guys are. Learn wtf you're talking about. It's my fault I starved my system? Uh, the kernel is my hardware's handler, and it needs to handle all loads thrown at it correctly, including ones that require it to swap memory to an outside cache. Which it currently fails to do correctly, causing the system to basically die. And maybe I'd use SysReq keys, if only my fucking desktop worked to google it when I needed them, huh? I know OF them, but why tf should I use them when I shouldn't have to? Moronic. Absolutely moronic. Shouldn't EVER be required to voodoo anything on a modern system.

Stop telling people how to use their hardware. If they're not using it wrong, which using it in any way allowed. This ABSOLUTELY includes straining its resources, ALL RESOURCES. The system shouldn't die, period. Does ethernet die if you use 100% of its bandwidth at one time? NO. Does USB die when you use all its bandwidth? NO. Anything other than handling the issues gracefully is a bug. Windows even throws most of the crap it'll never use on disk cache ACTIVELY, at least in ~Windows 7 days. And it did it by default. The Linux kernel, while definitely not doing it as aggressively as Windows , should at least be able to do the same without needing the PC-Heimlich. Anything else is a bug, and the people saying stay in your limits are being a cancer by ignoring an issue that needs attention.

Absolutely moronic to suggest its a user issue, you people. I'm pretty sure Linus Torvalds even had a rant against some bullshit like that relating to breaking user space. Go find it, read it, and self reflect how dumb your replies suggesting the user is the issue is the problem.