systemd-oomd Looks Like It Will Come Together For systemd 247

[starshipeleven]

And you don't have examples.

Lol? No I don't have examples of something I never claimed in the first place.

[starshipeleven]

They didn't build it for desktop systems, but I too see where this could be used on desktop on a few things. Auto Kill a few things, or the the system hang?

There is not a whole lot of difference between a desktop and a server in a OOM situation, and this daemon is smarter than Linux kernel's own OOM functionality. It will act before the system starts lagging and freezing because of low RAM.

[tildearrow]

If you think systemd killing process is a disaster waiting to happen, you won't believe what disasters the kernel OOM actually does reliably. Like soft-locking the system in an unresponsive mode if there is swap at all.

Not everyone enjoys babysitting a machine that can and should deal with it on its own

Is there a way to prevent Linux from swapping executable code? This would solve a big part of the slowdown...

[starshipeleven]

Is there a way to prevent Linux from swapping executable code? This would solve a big part of the slowdown...

afaik Linux swapping logic isn't granular enough to not swap executable code. It sees RAM pages or something, it's just checking how often they are touched or read.

But I'm not seeing how that matters, if it swaps most of a process's memory the performance will be trashed even if the executable code is kept in RAM.

There were some guys on these forums that were talking about slowing down process execution for swapped processes and not lock the system in wait for some swapped process IO to finish, or something like that. So that only the processes that have their memory swapped to disk will lag and become unresponsive, not the whole system.

This would allow swap to become Great Again (tm), or at least serve some useful purpose.

[haplo602]

One word: ignorance.
Again, people that don't know what they're talking about and haven't got the first clue about how Linux handles OOM situations ideologically condemn it because it has "systemd" in its name.

I may be the ignorant one here .... but why can't they simply improve the already available OOM mechanism in the kernel ? So far I don't see any need for this to be systemd exclusice ?

That's also a main issue with systemd haters from what I can see. It gobbles up various things that originated elsewhere and improves them killing the original project in the process... very Microsoft-like if you ask me ...

[starshipeleven]

I may be the ignorant one here .... but why can't they simply improve the already available OOM mechanism in the kernel ?

many in the kernel development (also Torvalds) don't even acknowledge the problem. Getting a fix merged is a uphill battle and not really worth it when you can do the same with a userspace application.

Let's not forget that software is still a tool to reach an objective.

So far I don't see any need for this to be systemd exclusice ?

It's still not a systemd exclusive, many daemons, tools and libraries from systemd project work fine alone.

It gobbles up various things that originated elsewhere and improves them killing the original project in the process... very Microsoft-like if you ask me ...

How dare they offer a better alternative and how dares people migrate to their alternative.

We should maintain everything alive no matter how good or bad it is, because that's true software freedom.

[jacob]

I may be the ignorant one here .... but why can't they simply improve the already available OOM mechanism in the kernel ? So far I don't see any need for this to be systemd exclusice ?

The kernel's OOM mechanism is a different thing and serves a different purpose. A policy-based userland component that is cgroup aware is needed, and systemd is the simplest way and most logical place where to implement it.

That's also a main issue with systemd haters from what I can see. It gobbles up various things that originated elsewhere and improves them killing the original project in the process... very Microsoft-like if you ask me ...

This is partly a myth. Systemd "gobbled" udev, which was originally developed by Kay Sievers who is also a systemd developer. In short he decided to merge those two projects of his. Why shouldn't he?

Systemd also "gobbled" logind (ex-ConsoleKit), which was unmaintained abandonware. Again, what exactly is the problem? Would you prefer it to be unmaintained rather than seeing its development resume under an umbrella that happens to be called "systemd"?

But more importantly, the comparison to Microsoft makes no sense. Microsoft's absorption of existing independent software is a problem when MS makes it proprietary and enforces user lock-in. Systemd does nothing of the sort, it's fully FOSS. To my knowledge so far systemd has not pre-empted any projects (as in forking it, merging it in and driving the original out of existence). But if it did or if it does at some point in the future, so what? That's also what FOSS is for, you know. You may have developed something but if another group of developers comes in, merges it into their own codebase under the terms of the FOSS licences YOU selected to release it, and then provides a better user experience thanks to a more integrated and more tightly coupled environment, then d'uh. No project has an entitlement to always remain relevant, it's called Darwinian evolution.

[starshipeleven]

The kernel's OOM mechanism is a different thing and serves a different purpose. A policy-based userland component that is cgroup aware is needed, and systemd is the simplest way and most logical place where to implement it.

Not sure how the OOM mechanism in the kernel serves a different purpose. It's so much dumber, but it's still aiming at the same thing, and also has some basic way of setting policy about what is more and less important (the process "oom_score" in sysfs, among others).

Also not sure why you coudln't make a kernel system that would follow policies set by userspace, tracking cgroup (which is a kernel feature among other things). Plenty of kernel functionality requires a userspace management daemon to load policies and such. Like for example the firewall and routing tables, and even the current OOM system (although it's limited).

EDIT: my point is that the decision to work in userspace instead than in kernel is a political one, i.e. they can't be arsed to fight tooth and nails for something that kernel developers may or may not fully understand or believe in.

[halo9en]

This would allow swap to become Great Again (tm), or at least serve some useful purpose.

Um, yeah, I haven't used a swap file in the last 5-6 years (current desktop: 16GB RAM) and live perfectly fine without it...

[halo9en]

Systemd also "gobbled" logind (ex-ConsoleKit), which was unmaintained abandonware.

I despise Poettering with a passion but... ConsoleKit... nightmares resurface...