Bug 1472336 - System becomes unresponsive when swapping
System becomes unresponsive when swapping
Status: NEW
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-07-18 09:24 EDT by Steven Haigh
Modified: 2017-11-26 21:33 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 196729 None None None 2017-11-26 21:33 EST

  None (edit)
Description Steven Haigh 2017-07-18 09:24:02 EDT
After a fix to glibc that fixed Unity 3D based games (Fedora ref: https://
bugzilla.redhat.com/show_bug.cgi?id=1440287), I have noticed that when I play 
Cities: Skylines that the system becomes unresponsive when digging into swap.

I have 10Gb of RAM in this system and run Fedora 26. If I launch Cities: 
Skylines with no swap space, things run well performance wise until I get an 
OOM - and it all dies - which is expected.

When I turn on swap to /dev/sda2 which resides on an SSD, I get complete 
system freezes while swap is being accessed.

The first swap was after loading a saved game, then launching kmail in the 
background. This caused ~500Mb to be swapped to /dev/sda2 on an SSD. The 
system froze for about 8 minutes - barely being able to move the mouse. The 
HDD LED was on constantly during the entire time.

To hopefully rule out the above glibc issue, I started the game via jemalloc - 
but experienced even more severe freezes while swapping. I gave up waiting 
after 13 minutes of non-responsiveness - not even being able to move the mouse 

During these hangs, I could typed into a Konsole window, and some of the 
typing took 3+ minutes to display on the screen (yay for buffers?).

I have tested this with both the default vm.swappiness values, as well as the 
vm.swappiness = 1
vm.min_free_kbytes = 32768
vm.vfs_cache_pressure = 60

I noticed that when I do eventually get screen updates, all 8 cpus (4 cores / 
2 threads) show 100% CPU usage - and kswapd is right up there in the process 
list for CPU usage. Sadly I haven't been able to capture this information 
fully yet due to said unresponsiveness.

This seems to be a relatively new problem that I did not encounter during the 
Fedora 26 beta - but do now.
Comment 1 Steven Haigh 2017-07-18 09:25:32 EDT
Forgot to add kernel version!

Currently testing with:

Note You need to log in before you can comment on or make changes to this bug.