Почему kswapd использует 100% ЦП без места подкачки и большого количества кеша, доступного для пожинания?

Firefox использовал много памяти, и машина почти полностью остановилась из-за kswapd / kworker, использующего большую часть процессоров. Нет места для подкачки, и vm.swappiness = 0 в Linux 4.5.7 (Fedora 24).

Я не понимаю, что с почти 1,5 ГБ буфера / кеша, почему не Разве Linux не пожинает этот кеш для Firefox / плагина-контейнера? Что делает kswapd?

top - 13:17:15 up  2:47,  4 users,  load average: 9.78, 5.38, 2.35
Tasks: 197 total,   4 running, 193 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.8 us, 47.0 sy,  0.0 ni, 10.0 id, 36.9 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem :  3922860 total,   105508 free,  2353620 used,  1463732 buff/cache
KiB Swap:        0 total,        0 free,        0 used.     6828 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   49 root      20   0       0      0      0 R 100.0  0.0   2:35.25 kswapd0
 6395 kevin     20   0 1152968 371132   4292 R  31.7  9.5   3:16.59 plugin-containe
 3449 root      20   0       0      0      0 S  26.3  0.0   0:24.49 kworker/u16:3
 5885 root      20   0       0      0      0 S  23.8  0.0   0:34.12 kworker/u16:2
 4246 root      20   0       0      0      0 S  22.9  0.0   0:42.11 kworker/u16:4
 6236 root      20   0       0      0      0 R  19.0  0.0   0:38.84 kworker/u16:1
 4700 root      20   0       0      0      0 S  17.8  0.0   0:40.57 kworker/u16:5
 3473 kevin     20   0 1662688 402008    460 D   8.3 10.2   7:36.45 thunderbird
 1846 elastic+  20   0 4238960 401324    124 S   5.7 10.2   3:05.58 java
 6107 kevin     20   0 2133616 602096  20920 S   5.1 15.3   4:03.21 firefox...

Я не думаю, что в последнее время делал что-либо, связанное с вводом-выводом и записью, поэтому я не ожидал бы сброса грязных страниц на диск (SSD), хотя ожидание составляет 37%, что немного удивительно . Я взял около 30 секунд top и buff / cache не сильно изменилось, поэтому я не думаю, что на самом деле он сбрасывает какие-либо страницы на диск (хотя тогда я не Не понимаю, почему высокий% ожидания):

$ grep -e "top -" -e "buff/cache" top.txt 
top - 13:17:11 up  2:47,  4 users,  load average: 9.41, 5.23, 2.29
KiB Mem :  3922860 total,   103468 free,  2353456 used,  1465936 buff/cache
top - 13:17:15 up  2:47,  4 users,  load average: 9.78, 5.38, 2.35
KiB Mem :  3922860 total,   105508 free,  2353620 used,  1463732 buff/cache
top - 13:17:21 up  2:47,  4 users,  load average: 10.44, 5.59, 2.43
KiB Mem :  3922860 total,   108700 free,  2354532 used,  1459628 buff/cache
top - 13:17:24 up  2:47,  4 users,  load average: 10.72, 5.73, 2.50
KiB Mem :  3922860 total,   107004 free,  2355112 used,  1460744 buff/cache
top - 13:17:43 up  2:47,  4 users,  load average: 12.64, 6.39, 2.77
KiB Mem :  3922860 total,   108264 free,  2352820 used,  1461776 buff/cache
top - 13:17:46 up  2:47,  4 users,  load average: 12.27, 6.42, 2.79
KiB Mem :  3922860 total,   108580 free,  2352584 used,  1461696 buff/cache

Удаление firefox и плагин-контейнер вернуло систему в нормальное состояние. Я бы предпочел, чтобы либо кеш был полностью очищен, чтобы дать больше места, либо, по крайней мере, чтобы убийца OOM работал в этом состоянии вместо того, чтобы делать Ctrl + Alt + F2 , потому что KDE не отвечает, вечное ожидание приглашения на вход и, наконец, выполнение pkill .