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

Разжуйте, если не в лом, что это за зверь - MGLRU

MGLRU

Это что?

le9 патч остановился в развитии - Почему, конкурент от гугла сильно лучше?

MGLRU
Это что?

На ЛОРе месяцами кипели обсуждения le9-патч, между hakavlad и post-factum, который сначала воспринял в штыки новинку, а потом проникся ) и добавил в свое ядро pf-kernel.
Когда же гугловцы пробудились от спячки ) и взялись за доработку своего аналога MGLRU (используется в андроиде и chromeos), то и post-factum отказался от le9 в его пользу, мотивируя скорым внесением в апстрим.

MGLRU

Текущее восстановление страницы слишком дорого с точки зрения использования ЦП, и это часто делает неверный выбор в отношении того, что выселять. Этот набор патчей предлагает альтернативное решение, которое является эффективным, универсальным и простой.

p.s. А теперь в тему приходит народ и спрашивает, а что это такое? ‘Копья’ обсуждений ломались где-то там, на задворках форума. :)

Вместо того чтобы установить ulimit и запретить оверкоммит, они выдумывают упреждающий OOM-киллер. «Господь, жги!» (c)

писать нормальный код и планировать ресурсы - нафиг надо.
мы будем экономить на всём, писать говнокод, впихивать вселенную во невпихуемое и фикисить oom-killer.

Я поставил 8Гб ОЗУ, и ff перестал падать, но, интересно, да!

еще не все дистрибутивы используют своп на zram

Да, потому что zswap более эффективен при физическом свопинге, а свопиться не имея физической подкачки это путь к самоубийству.

как одно другому мешает?

Если ресурсы распланированы правильно и код не багнутый то приход oomd лишь создаст новую проблему.

Считаю, то, что переработанный и улучшенный MGLRU будет добавлен в ядро 5.20, полностью заслуга hakavlad.

Это он поднял тему неэффективной работы памяти, это он создал свой le9-patch и показал его на всех публичных площадках, рассказал о нем множеству групп пользователей. Он так громко тряс линукс-сообщество, что это краем задело гугловских инженеров. :)

Это я так, написал хоть одно положительное сообщение в куче осуждающих, непонимающих и «и так нормально, я поставил 64G+ и система больше не зависает при работе браузера».

MGLRU будет добавлен в ядро 5.20, полностью заслуга hakavlad.

Бред.

mglru появился до начала миох работ с ле9. Вообще независимо развивался. Я не имею отношения к мглру.

свопиться не имея физической подкачки это путь к самоубийству

Почему? Сжатый своп это просто способ сжимать память. Я согласен, что без физического свопа можно разве что кубернетес-кластеры крутить, где вся архитектура заточена под убийство процессов, но если людям хочется иметь такое поведение на своём десктопе, почему бы нет.

Я про добавление в линукс-ядро. То что эти патчи появились не вчера, я в курсе.

Имхо, без шумихи вокруг le9, никто бы в гугле и не пошевелился. У них был свой междусобойчик с MGLRU в ChromeOS и Android, проблемы Linux-дистрибутивов их не интересовали и не интересовали бы и дальше.

Но это мое мнение, и оно вот так сложилось.

Дополню. Мое знакомство с MGLRU пришло через знакомство le9 в ядре pf-kernel. И если бы post-factum продолжил его поддержку, я бы и сейчас его юзал. Но мне проще пользоваться готовыми продуктами, чем компилить самому, да и не вижу в этом необходимости.
Знаю, что еще осталась поддержка le9 в linux-xanmod, но я уже привык к одному ядру.

Ну так пусть себе настраивают и сами потом огребают, но это не в коем случае нельзя включать как дефолтное решение. А его и включают, и даже рекомендуют, и потом ещё находятся перцы, которые жалуются что это организация памяти в ядре неправильная и надо всё срочно переделать и внедрить oomd в базовую систему.

Почему, конкурент от гугла сильно лучше?

Если бы. На кор2 с 2 гигами памяти пока ещё не придумали ничего лучше, чем le9.

https://www.phoronix.com/news/MGLRU-Maple-Tree-Miss-6.0

MGLRU и Maple Tree не получат Linux 6.0, но нацелятся на Linux 6.1

:)

Сначала речь шла о 5.19. потом 5.20 (6.0), сейчас опять передвинули. Так post-factum окажется пророком, ) Тестируем Linux 5.12—5.17 с патчем Multigenerational LRU Framework (комментарий)

В 6.5 скорее, не раньше.

Разумеется. Это я еще не репортил особенности MGLRU, с которыми можно повесить систему в определенных конфигурациях и нагрузках (когда со страрым LRU проблем нет).

А тем временем в OpenWrt 21.02 вот такой забавный дефолт:

vm.min_free_kbytes = 16384

Напомню: в дистре, заточенном бегать на 64МБ.

кстати https://gitlab.com/post-factum/pf-kernel Page Not Found

Переехал на codeberg. Я, как пользователь pf-kernel, должен быть в курсе. ) https://codeberg.org/pf-kernel/linux/wiki/README

забавный дефолт

Это при каком объеме памяти? Оно ж уменьшается при уменьшении MemTotal.

При 128.

Настрой в zram это https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docum... и забудь про zswap.

Вау, крутой костыль. Это же целый свопинг для виртуального блочного устройства для свопинга! За исключением дублирования функционала, мы получим целый zswap на выходе!

Блин, ЗАЧЕМ они это делали?!

🤦‍♂️

Это мне надо убивать себя фэйспалмом. Преимущество zswap над zram в том, что он исключает ненужное виртуальное блочное устройство из процесса. Нет, блин, давайте добавим ещё одну бессмысленную прослойку и вместо своп-раздела планировщика памяти создадим дополнительный своп-раздел для виртуального блочного устройства.

🤦‍♂️🤦‍♂️

А можно чуть больше подробностей для тех, кто не умеет читать эмодзи?

Подробности по ссылке выше, читай.

Я вижу документацию по настройке, но не вижу там пояснений, зачем это нужно. Можешь разжевать?

The current plan is to merge MGLRU into -mm soon and to
later reintroduce mapletree, with a view to hopefully getting both into
5.21-rc1.

– https://lore.kernel.org/linux-mm/20220803133541.18b82ec9344ed0e8b975fe5b@linux-foundation.org/

Так что вероятность слияния MGLRU c 521 крайне высока.

К чему такая категоричность? Оба решения имеют свои плюсы и минусы.

Блин, ЗАЧЕМ они это делали?!

Потому что почему бы и нет? zram может использоваться не только для своппинга, и в некоторых случаях backing_dev может иметь полезное применение.

backing_dev принимает только несжимаемые страницы (в отличие от обычного своп-раздела при использовании zswap, в который падают все несжатые страницы - страницы декомпрессируются перез записью в своп), что может иметь свои плюсы - на диск упадут только несжимаемые страницы, а не все подряд, как при использовании zswap.

исключает ненужное виртуальное блочное устройство

Во-первых, не ненужное, во-вторых, что плохого в дополнительном устройстые? Тебе одной станицы памяти жалко, которая используется для его создания?

см чуть выше пояснения

Сначала речь шла о 5.19

Никогда не шла, это были фантазии форониксов. А про принятие в 520 уже пришет Мортон, а не абы кто. Если не будет новых возражений, то, вероятно, таки примут в 521.

установить ulimit и запретить оверкоммит

Трудно придумать решение глупее.

Архитектура может быть такой: оомд детектит проблему и дает команду включить новые контейнеры и увеличить RAM при возрастании нагрузок - на сервера может возникнуть внезапный наплыв пользователей, например. оомд - это не только убийца, но и детектор проблем и кастомный обработчик этих проблем.

В федоре по дефолту зрам и брат жив. Никаих zram-специфичных проблем нет.

потом ещё находятся перцы, которые жалуются что это организация памяти в ядре неправильная и надо всё срочно переделать и внедрить oomd в базовую систему.

Как раз тки сначала был тред с жалобами, и как решение проблемы включены zram и earlyoom/oomd. И проблема исчезла - федора летает, зависаний нет.

свопиться не имея физической подкачки это путь к самоубийству

Счего ты взял? Всегда своплюсь без подкачки на ПЗУ, брат жив.

zswap более эффективен при физическом свопинге

Возможно. Но если нет потребности в огромном своп-разделе, то zram достаточно.

Тебе одной станицы памяти жалко, которая используется для его создания

Там вероятно не одна страница, и там будет весь механизм работы с блочным устройством и со своп-файлом, и возможно ещё и i/o шедулер свои очереди приплетёт (хз, может там не всегда noop). Короче работа с zram весьма затратна по цпу, и идёт на скорости порядка 20-30% от скорости сжатия алгоритма.

Ну, это всё верно для свопинга на zram. Если zram используется для других целей, тогда да, это всё не актуально.

Вот только его обычно не используют в роли гибкого детектора проблем, а скорее в качестве военно-полевого суда. Особенно когда он запихан в дистр по дефолу.

летает, зависаний нет

А убитых процессов тоже нет? Потому что это тоже косяк, это всё таки не какой нибудь псевдо-многозадачный андроид.

Всегда своплюсь без подкачки на ПЗУ, брат жив.

Ну, допустим. А как это сочетается с довольно хорошей идеей повесить /tmp в tmpfs? Которая в современных реалиях должна быть гигов 15-20 (при допустим 8 гигах оператики) и туда внезапно может упасть десяток гигов несжимаемых данных, и это надо не только переварить без резьни процессов, но также эти данные не должны осесть там мёртвым грузом, по сути выключив из работы и сам zram, и всю занимаемую им оперативку.

Но если нет потребности в огромном своп-разделе, то zram достаточно.

И вот как раз по причине /tmp мне кажется что такая потребность в современных дистрах есть.

по сути выключив из работы и сам zram, и всю занимаемую им оперативку.

Убунтята, не проходите мимо: le9 patch добавлен в linux-xanmod и ваш OOM killer будет вылечен (комментарий)

будет убит

Ключевые слова. Задача не будет выполнена.

Может стоит писать программы менее требовательными к ресурсам? Память там экономить, место на диске, быстрые алгоритмы использовать.

Ваши OOM-киллеры - это лечение умершего.

Может стоит писать программы менее требовательными к ресурсам?

Нет.

Память там экономить

Глупости какие.

Ваши OOM-киллеры - это лечение умершего.

ООМ килл - это отрубание хвоста ящерицы, сохранение всей системы и ее управляемости за счет смерти одного процесса.