Bug 23270

Summary: kswapd doesn't like swappiness=0
Product: Mageia Reporter: Dag Nygren <dag>
Component: RPM PackagesAssignee: Kernel and Drivers maintainers <kernel>
Status: RESOLVED OLD QA Contact:
Severity: normal    
Priority: Normal CC: marja11, ouaurelien
Version: 6   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: kernel-server-latest CVE:
Status comment:

Description Dag Nygren 2018-07-03 10:42:05 CEST 
Description of problem:
A long time ago I set up my laptop to use as little disk as possible to save the battery by setting vm.swappiness = 0 in /etc/sysctl.conf .
A long time after that I started having strange lockups in my system. Constant disk access and no response. The only way out was a reboot. Now finally found by  having a top running when it happened that the reason seems to be that kswapd keeps accessing the disk even if no swap should happen and he also comsumes quite a lot of CPU doing this. Some Googling told me that the meaning of swappiness=0 has change somewhere around kernel version 3.5 from "swap only when absolutely necessary" to "never swap". The kernel version would fit with the introduction of the problem. Current Firefox pages seems to trigger the need for swap more and more (I do have 6G memory - Should be plenty...) Anyway setting swappiness to 1 seems to have fixed the problem. There will be nothing in the log files and OOM never sets in.

Version-Release number of selected component (if applicable):
Kernels after 3.5

How reproducible:
Always

Steps to Reproduce:
1. Set vm.swappiness = 0 in /etc/sysctl.conf and apply
2. Run something that requires swap
3. See the system grind to a halt with constant disk access and high CPU usage by kswapd


The problem is obviously a kernel bug, but I was told to report it to the distro maintainer.... I am personally fine now, but think the kernel should handle this condition more gracefully.
Comment 1 Dag Nygren 2018-07-03 10:46:12 CEST 
Sidenote on this:

What in Mageia 6 is locking almost 3GB in reserved buffers?

Tested by running "top" in one window and entering
"echo 3 > /proc/sys/vm/drop_caches", which should drop all the caches that are not locked.

Still have almost 3GB in buff/cache field of top....
Marja Van Waes 2018-07-04 12:47:19 CEST

CC: (none) => marja11
Assignee: bugsquad => kernel

Comment 2 Aurelien Oudelet 2020-08-16 17:37:06 CEST 
Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan 
to fix it in a currently maintained version, simply change the 'version' to 
a later Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we 
weren't able to fix it before Mageia 6's end of life. If you are able to 
reproduce it against a later version of Mageia, you are encouraged to click 
on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a more recent
Mageia release includes newer upstream software that fixes bugs or makes them
obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Best regards,
Aurélien
Bugsquad Team

Resolution: (none) => OLD
Status: NEW => RESOLVED
CC: (none) => ouaurelien