Современное состояние обработки нехватки памяти в линуксах: MGLRU и le9 патчи и юзерспейсные киллеры

Отключай с 640 kB, разрешаю.

При любом количестве можно. Кто ж запретит отключать?

Инженер Google экспериментирует с обработкой ZRAM для нескольких потоков сжатия
коммент выше

Продолжение истории, Linux 6.2 поддерживает несколько потоков сжатия с ZRAM

С помощью этой работы ядра можно было бы использовать вторичный алгоритм сжатия с более высоким коэффициентом сжатия, хотя и более медленной скоростью сжатия/декомпрессии в зависимости от того, что попадает в ZRAM или, если первичный алгоритм сжатия не смог сжать содержимое.   

Это может использоваться для таких вещей, как повторное сжатие простаивающих/холодных страниц с более высоким алгоритмом/уровнем сжатия, сжатие огромных страниц с помощью Zstd, или для различных других возможных случаев использования. Пользовательское пространство может управлять этой поддержкой потоков сжатия в ZRAM.   


Компания Google, работающая над усовершенствованием ZRAM, похоже, намерена использовать эту технологию в Chrome OS. 

Заметил один нюанс, после перехода на ядро 6.1. Когда после длииительного uptime уже ‘подзабиты’ ram и zram, и я запускаю какой-либо iso в qemu, то все конкретно подвисает, а одно из ядер процессора загружено на 100% (но иксы перезагружаются с Ctrl-Alt-Backspace).
Причем на ядре 6.0 ничего такого и близко не было, при тех же вводных.

Решение:
У меня ядро pf-kernel. Недавно было обновление v6.1-pf4 и одним из исправлений прописано «the khugepaged regression commit has been reverted». Пока юзаю, проблем нет.

Что такое khugepaged и для чего, слабо понимаю из описаний, :) но поиском нашел похожее Fixing khugepaged CPU usage VMware Workstation. (Пробовал настройки на предыдущей версии pf, вроде есть положительное влияние c never).

p.s. Не знаю, сталкивались ли с похожим на ванильном ядре, но решил написать для истории. 🙂
Именно в этой теме, а не в «Linux 6.1», все же относится к настройкам и механизмам работы памяти.

Попытался просто открыть базу в keepassxc, вот так давление по памяти подскочило на примерно минуту:

mikhailnov@hp-xfce ~ $ uname -a
Linux hp-xfce 6.1.4-generic-1rosa2021.1-x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jan  8 03:35:33 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
mikhailnov@hp-xfce ~ $ cat /proc/pressure/memory 
some avg10=1.43 avg60=25.28 avg300=12.62 total=52334980
full avg10=1.43 avg60=25.27 avg300=12.59 total=51228024

Обычно подобное иногда возникает при попытке запустить виртуалку qemu.

В 6.1.10 уже есть откат регрессивного коммита: https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/e1275a6b2d993b92a7202b1154b4b6a7cf745646%5E%21/#F0

Утром в куплете, вечером в газете. (c)

Реализовано в ядре 6.2:

В устройстве zRAM, позволяющем хранить раздел подкачки в памяти в сжатом виде (в памяти создается блочное устройство на которое производится своппинг со сжатием), реализована возможность переупаковки страниц с использованием альтернативного алгоритма для достижения более высокого уровня сжатия. Основная идея в предоставлении выбора между несколькими алгоритмами (lzo, lzo-rle, lz4, lz4hc, zstd), предлагающими свои компромиссы между скоростью сжатия/распаковки и уровнем сжатия или оптимальными в особых ситуациях (например, для сжатия больших страниц памяти).
Релиз ядра Linux 6.2

Может со временем станет стандартом именно такое использование zram, одновременно с разными алгоритмами сжатия.

Обещают новинки для 6.11 в управлении памятью:

В рамках изменений в управлении памятью, которые, как ожидается, будут объединены в предстоящем цикле Linux 6.11, предполагается более точный контроль над настройкой подкачки, используемой для определения того, насколько интенсивно страницы перемещаются из физической системной памяти в пространство подкачки на диске.

В новом коде из Meta для memory.reclaim поддерживается аргумент swappiness. Это эффективно обеспечивает более детальный контроль над поведением swapiness без переопределения глобального параметра swappiness.

For example:
echo "2M swappiness=0" > /sys/fs/cgroup/memory.reclaim
will perform reclaim on the rootcg with a swappiness setting of 0 (no swap) regardless of the vm.swappiness sysctl setting.

Хорошие новости для пользователей systemd-oomd и других, желающих получить больший контроль над поведением Linux swapiness.
*Linux 6.11 Предлагает более точный контроль над возможностью подкачки
*Сам патч