Fedora Developers Discuss Ways To Improve Linux Interactivity In Low-Memory Situations

[phoronix]

Phoronix: Fedora Developers Discuss Ways To Improve Linux Interactivity In Low-Memory Situations

Similar to the recent upstream Linux kernel discussions over the poor Linux desktop experience when in memory pressure situations particularly with systems having limited amounts of RAM, Fedora developers are discussing ways to improve this experience as well...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Linux-Better-Low-RAM

[L_A_G]

I consider this recent hubbub about how Linux behaves when you disable the swap partition and then force it to run out of memory equivalent to complaining about how you end up in a ditch when you cut the brake lines on a car and then drive it down a very steep hill with an equally steep bend at the bottom.

Those brakes were what was supposed to stop you from ending up in that ditch...

Edit: To clarify to the people who think Windows does this better; The way it works is that rather than having a dedicated swap partition it just uses the partition the OS is installed on as swap and when it runs out of space it'll lock up all the same. It really doesn't solve the issue of running out of RAM and swap space, it just makes this happening less likely in some scenarios, but more likely in other scenarios.

[Neraxa]

The situation with the lockups is a Denial Of Service security vulnerability present in the kernel for at least 8 years. I have seen these lockups happen that long. Someone with local access can use this to lock up the system. The kernel developers know about this problem apparently but choose not to do anything about it. Locking up is not an acceptable behaviour in low memory, period.

I have seen in some situations the lockup occur in situations where physical RAM is nearly exhausted with about 200 MB free on a 8 gb system with 4 GB of swap space. Very little swap space had yet been used so most swap was free. Therefore, this is not an OOM killer issue becuase it was still gigabytes away from running out of swap space. Killing firefox resolves the issue. The system is nearly locked up and can take a very long time to just issue a kill command. Once firefox is killed the system is unlocked and acts normally again. This seems to indicate there is something else than an OOM killer issue, instead looks like there is something going on with i/o scheduling, process scheduling, caching or paging.

Anyway regarding what do when all RAM and Swap has run out, what I would prefer is to be able to configure it to kill applications on a list of programs, in particular firefox would be a good candidate for many users, and/or proceses that should be left alone. By default, critical processes including X and the window manager should not be killed, of course. I have however seen Linux kill X which is a stupid thing to do.

I would like to see an kernel API be added so an external monitor program can be configured to be notified of an OOM condition and throw up for the user a list of programs so the user can decide which ones that should be killed to free more space and give the user advance warnings about memory. This includes an API for this monitor program to detect when the OOM condition has gone away so the dialog can be withdrawn.

[AsuMagic]

I consider this recent hubbub about how Linux behaves when you disable the swap partition and then force it to run out of memory equivalent to complaining about how you end up in a ditch when you cut the brake lines on a car and then drive it down a very steep hill with an equally steep bend at the bottom.

Those brakes were what was supposed to stop you from ending up in that ditch...

Linux behaves at least just as poorly even when you have the swap partition up.
You usually cannot even swap to another TTY for a while, and the entire desktop gets entirely frozen.
Even Windows does better. Nobody cares about the technical explanation, if even Windows does something better than Linux on the desktop, then there is something wrong.

If you have a program unexpectedly eating up your RAM, your system will lock up for a while, swap or not.
It only is even more ridiculous when you do not have swap, because your system just decides to lock up for a few minutes until it decides it might be a good idea to kill the faulty process.

[Neraxa]

I consider this recent hubbub about how Linux behaves when you disable the swap partition and then force it to run out of memory equivalent to complaining about how you end up in a ditch when you cut the brake lines on a car and then drive it down a very steep hill with an equally steep bend at the bottom.

Those brakes were what was supposed to stop you from ending up in that ditch...

Wrong. If there is no swap space, and the system runs out of RAM, it should not lock up. Period. Full Stop. If there is swap, the swap can run out, your out of memory still, so swap will not gaurantee the system will not run out of memory. Swap should not be relied on to keep the kernels faulty handling of low memory from occuring. The kernel should not lockup in low memory situations.

Locking up is not an acceptable solution when running out of RAM or swap.

Killing off X so the user ends up with a blank screen is not acceptable either. What would be acceptable is to protect criticial processes, and ask the user which program to kill, or to kill off a program such as firefox which uses the most ram but is not critical and let the user configure what they want to happen.

[birdie]

I consider this recent hubbub about how Linux behaves when you disable the swap partition and then force it to run out of memory equivalent to complaining about how you end up in a ditch when you cut the brake lines on a car and then drive it down a very steep hill with an equally steep bend at the bottom.

Those brakes were what was supposed to stop you from ending up in that ditch...

I could have called you a Re Tardo or a bloody idiot who repeats the old falsehoods but I won't.

SWAP does not solve this issue. At best it can postpone it. If you still don't believe me, read the LKML - Linux kernel developers have admitted the issue exists and many of them frequently experience it with or without SWAP enabled.

[bug77]

Yes, this! Let's talk killing processes automatically. Because what could possibly go wrong?

[birdie]

The easiest solution for Fedora (and other Linux distros) would be to enable earlyoom by default. The package is already included in Fedora.

The discussion about this issue in LKML has died out - I might be mistaken but by the look of it, kernel developers have forsaken the issue which kinda sucks since it's existed for as long as I remember Linux.

Yes, this! Let's talk killing processes automatically. Because what could possibly go wrong?

What could go wrong when the system is completely hobbled and you have no indication whether it will ever return to a normal state.

I wonder how many idiots in this thread will continue vindicating this outstanding egregious issue.

[Britoid]

Yes, this! Let's talk killing processes automatically. Because what could possibly go wrong?

I'd rather my compiler get killed in an OOM situation than my display server.

[AsuMagic]

Yes, this! Let's talk killing processes automatically. Because what could possibly go wrong?

Obviously, the best solution is to just enter into a while(true) loop. This way, your precious processes won't be killed.