System should never drive into unresponsive swapping by naive end-user handling operations

Bug #1447052 reported by dronus
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
High
Unassigned

Bug Description

Even for the newest Ubuntu, even on memory rich high end systems sporting fast SSD drives, the system can be driven into long time swapping state with unresponsiveness (jerky mouse movements or no movement at all, no reaction to clicks and keypresses) easily by naive everyday operations. The state may last for hours depending on the applications behaviour, only workaround is to pull the plug. This is akward. Many users often have a quite messy desktop with several applications opened at once, hence a large risk of data loss if the system has to be restarted in an unresponsive condition.

This should not be blamed on bad behaveing applications alone, as there are a lot of naive applications around, and it is not the right of some desktop application to bring down the whole system.

Some example "mistakes" a "naive" user may do, the list may be easily extended endless:

-Open an oversized image or a long list of images in Gimp
-Mark an entire column in Libreoffice Calc and fill down with some complex formula
-Open a long collection of PDFs at once
-Accidently open some large ASCII database- or log file with Libreoffice Writer
-Pull up interactive sliders in Blender related to detail refinements
-...

I guess it is not easy to work around, but the current state is unbearable in my opinion.

This may also have security implications, as unresponsiveness prevent manual entering of screen locks, shotdown or standby, which may leave the machine unlocked, if the user leaves the unresponsive machine and it then recovers.

Revision history for this message
dronus (paul-geisler) wrote :

Anyone know about the state-of-the-art relating this problems on Windows or MacOSX ?

Revision history for this message
dronus (paul-geisler) wrote :

My personal workaround if I know I am doing something risky in respect to memory usage is to disable swap. The unresponsiveness than still kicks in (why is that either?) but the oom killer invents and bring down the runaway application and restores system usability, or the application kills itself on some memory allocation.

Revision history for this message
dronus (paul-geisler) wrote :

Thinking about it, it reminds me Douglas Adams' description of Arthur Dent ordering a decent cup of tea, thereby rendering the spaceships' computer busy and unresponsive for space navigation purposes.

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1447052

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
dronus (paul-geisler) wrote :

Due to the general nature of this bug, log files wouldn't provide any useful informations.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.0 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-vivid/

Changed in linux (Ubuntu):
importance: Undecided → High
tags: added: kernel-da-key
Revision history for this message
dronus (paul-geisler) wrote :

I tried the kernel 4.0.0-040000rc7-generic at a newer machine sporting Ubuntu 14.04.

It was hard to get it swapping as it some applications seems to be better now on itself, for example the newer Gimp seems to have a sophisticated virtual image memory by itself, so it almost never causes swapping anymore. However, using some applications under my development, I could trigger swap easily, like with the "Remesh"-Modifier of Blender. Swapping still renders the system unresponsive. On the other hand, I was able to recover from unusable state in reasonable time. I do not know if the newer kernel does anything smarter, or the test condition is not repeatable enough.

I will try to find an example every user could repeat that would reliable lead to unresponsiveness.

Revision history for this message
dronus (paul-geisler) wrote :

I must admit that while I encountered unresponsive swapping conditions about once a week, and seen other people encounter it, it is not easy to recreate them on demand :-)

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.