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

а что если у меня памяти с запасом в большинстве случаев, товарищ нищук?

У меня 16 Gb , но её я редко всю использую. Cтавить патч не имеет смысла наверно. И да - HDD.

Сделал отдельную заметку: https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/

По ссылке есть образ LiveCD Mint XFCE 20.1 с le9 и zram, для теста.

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

Когда система встаёт колом при заполнении всей памяти и свопа.

Это ж исправляется элементарно. Кто-то еще подвержен проблеме в 2021?

Ну у меня ок всё (до сих пор на питоновской версии сижу правда).

чего версии?

не всякая полезная работа столько сожрёт. на самом деле жрёт больше всего у меня как раз баловство(не игры)

кстати синтетика для воспроизведения пробуксовки

https://github.com/hakavlad/file-starve

можно ставить таймаут и целевой объем файл кэша

Итак, каковы итоги последних тестов?

Нет времени для тестов, работа.

Вчера грузил систему через tail /dev/zero. Ситуация получше, чем на ванильном ядре, но далека от того, что я предпочел бы видеть.

так и не выключил своп на HDD?

Это worst case, от которого пляшем.

Ну при работе без внешней подкачки придёт киллер во время интенсивной компиляции, убьет мне браузер… Так не интересно.

без внешней подкачки придёт киллер

Почему бы не поставить своп в zram и disksize= 2MemTotal? Какие с этим проблемы?

Как я предполагаю, следующим бутылочным горлышком является приоритизация IO. Условный tail /dev/zero уже не мешает размыванию списка чистых страниц, но мешает загрузке-выгрузке анонимной памяти других процессов.

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

В моих простейших тестах я просто по ключевому условию ставил такой процесс на короткий таймаут в страничном обработчике. Это помогало, но для общего случая нужно решение без таймингов.

Почему бы не поставить своп в zram и disksize= 2MemTotal? Какие с этим проблемы?

Эм… zram займёт всю оперативку?

zram займёт всю оперативку?

Не займет, если применять nohang c конфигом zram_checking_enabled=True. Также есть версия le9, защищающая мин объем анонимной памяти (патч не опубликован, однако пользуюсь сам именно им).

https://www.youtube.com/watch?v=o6GOz95sAnY

если данные хорошо сжимаются - улетят в своп

если плохо - zram займет много оперативы и оффендер будет убит

https://github.com/hakavlad/nohang-extra/blob/master/LE9/276.patch

а вот и патч

как тебе такое, post-factum

это патч, помогающий противостоять обнулению анонимки, если разрастается zram в оперативе (документации, правда, в патче нет к новому ключу)

Ну prelockd

Ну переписывание вроде и не планируется. Что не так с питоном? Без питона есть le9 патч - естественная альтернатива prelockd, не требующая демона.

Я не так выразился, а ты не так понял: меня версия на питоне полностью устраивает.

хорошо бы также en version

кроме него никто даже приблизительно не понял, о чем речь

Был адекват на опеннете еще:

Начинает тормозить потому что:
1. линуксу некуда деть анонимную память (свопа нет)
2. Единственно что можно выгрузить - это замеморимапленные с диска файлы. Например, запущенные программы и библиотеки.
3. Так как они по факту таки используются, то он их постоянно читает с диска, чуть поюзает и выбрасывает из памяти.
4. Потому что никто, блджад, не использует mlock() / mlockall() а надо! 

https://www.opennet.ru/openforum/vsluhforumID3/118068.html#6

Потому что никто, блджад, не использует mlock() / mlockall()

prelockd как раз решает проблему через mlockall()

эту статью бы на r/linux (при наличии en версии)

Подготовлю на днях, обязательно.

Ужас-ужас.

почему

Это worst case, от которого пляшем.

Зачем искусственно создавать worst case, если этого легко избежать? хромос, андроид и федора предпочитают своп только на zram. И многие другие дистрибутивы тоже.

zram - это наступивший мейнстрим, от которого и надо отталкиваться.

без внешней подкачки придёт киллер во время интенсивной компиляции

Вот сборка с -j512, никто не умер https://www.youtube.com/watch?v=nSCT_zZHYYQ

в файле подкачки

О Иисус, зачем использовать файл подкачки?

штраф на IO

тейлу практически не нужен IO. - Штраф получают процессы гуя, когда вытесняются их либы из памяти. От этого и зависит в основном - зависнет ли гуй или нет если своп на zram. Со swappiness=200 гуй не виснет, если нет подкачки на диске.

Ну ужас, но не «Ужас-ужас.». Каковы аргументы? Плох алгоритм? Плоха идея? Идея защиты анонимки кажется абсурдной? Но на дворе не 2010 и защита анонимки - важная задача.

Да, в 2010 была такая шутка:

swap would be intersting if we could somehow control swap thrashing. Maybe
we could add min_anonlist_kbytes. Just kidding:)

https://lore.kernel.org/patchwork/patch/222042/

Но в 2021 это жизненная необходимость.

Твой пример не ущербен в условиях маленькой и ОЗУ, а также в другом случае при прожорливом процессе готовом заполнить и 200-300 ГБ того что ему будет доступно в виде ОЗУ и/или подкачки.

Опять же совершенно глупое и однобокое отношение к «гую», типа это малозначительная фигня какая-то, программы второго сорта, ага.
У вас там всё нормально, алёоооо?
Люди пользуются графикой и она им нужна и отзывчивость системы важна.

Сейчас уже времена далеко после пентиума три и 128мб озу.
Двухъядерные ЦП очень распространены, озу минимум 2ГБ — в таких условиях нет причин выгружать графику и делать систему не отзывчивой и тем более позволять одному процессу совершенно бесконтрольно заполнить всю доступную память и при этом недоступную тоже (!) путём выгурзки кода «второго сорта», это просто бред, как ты на это не посмотри.

Подкачка будь то на диске или в ОЗУ как и исчерпание памяти вообще не должно влиять на отзывчивость графического интерфейса, 2021 год на дворе.

где я писал, что гуй не важен?

Подкачка будь то на диске или в ОЗУ как и исчерпание памяти вообще не должно влиять на отзывчивость графического интерфейса, 2021 год на дворе.

а кто с этим спорит? с каким невидимым собеседником споришь, отвечая на мои сообщения?

бесконтрольно заполнить всю доступную память и при этом недоступную тоже (!)

Что такое недоступная память?

Код всяких либ и прочих иксов выгружаемых из озу.
Кавычки забыл поставить.
А так может неверно сдетекти твои некоторые взгляды.

О Иисус, зачем использовать файл подкачки?

«Всё есть файл» (с)

Со swappiness=200 гуй не виснет, если нет подкачки на диске.

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

Вот сборка с -j512, никто не умер

Я вот сейчас утром к компу подошел, а там вся оперативка занята, и 4 гига в свопе. А мне некогда смотреть, кто течет и почему — работать надо. Такие дела.

Проблема решается отключением подкачки на диск. Зачем создавать проблему в виде медленной подкачки, а потом жаловаться на нее?

А мне некогда смотреть, кто течет

в таком случае проблему решит Alt+SysRq+K

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

Так не суй себе палку в колеса. Напоминаешь велосипедиста из известного комикса.

это такая большая проблема определить, что страница памяти очень редко используется и только тогда сбрасывать её на диск, получая все профиты без недостатков?

это такая большая проблема определить, что страница памяти очень редко используется и только тогда сбрасывать её на диск

Так обычно и происходит - в своп идут неактивные страницы. Однако механизм выбора неактивных страниц может быть несовершенен, вследствие чего и предложен Multigenerational LRU Framework.

Проблема решается отключением подкачки на диск. Зачем создавать проблему в виде медленной подкачки, а потом жаловаться на нее?

Я уже выше говорил, проблема решалась простым патчем на ядро в версии 4.xx-какой-то. Если будет время, повторю под современным.

Так не суй себе палку в колеса. Напоминаешь велосипедиста из известного комикса.

Напоминает аргументы отрицателей зависонов линукса:

Так не запускай жирные процессы, если мало памяти! Купи еще памяти!

смотреть, кто течет

$ oom-sort

Покажет кто течет. https://www.mankier.com/1/oom-sort

Покажет кто течет.

У меня только Xorg занимает 1.5G RSS и не худеет до полного ресета сеанса. Течет, ясен пень, не Xorg, а клиенты.

Пользователи ищут исправление зависаниям по меньшей мере с 2008 года (bug 12309 https://web.archive.org/web/20200206024633/https://bugzilla.kernel.org/show_bug.cgi?id=12309 ). Эта проблема настолько распространена и очевидна, что про неё есть статья на lurkmore, а её обсуждение из года в год поднимается среди профессионалов https://www.opennet.ru/opennews/art.shtml?num=51231 .

Так это ж две разных проблемы.

12309 - проблемы при копировавнии. Во втором случае - отказ в обслуживании при дефиците кэша (хотя первая проблема может быть частным случаем второй - нехватка кэша может провоцироваться копированием (чистый кэш вытесняется грязным)).

проблема решалась простым патчем на ядро в версии 4.xx

Что за проблема? Что за патч?

Напоминает аргументы отрицателей зависонов линукса:

Так не запускай жирные процессы, если мало памяти! Купи еще памяти!

Это у тебя странная аргументация:

Я сделал своп на HDD, и система виснет!

Из серии:

Я сделал swappiness=0 и система виснет! Я выключил юзерспейсные киллеры, и система виснет! Я использую все худшие практики, и система виснет!

Так зачем ты используешь худшие практики? Используй лучшие практики вместо худших.

Это у тебя странная аргументация

У меня аргументация нормальная. Жрущий процесс не должен оказывать существенного влияния на отзывчивость других компонент системы вне зависимости от деталей конфигурации системы подкачки.

Это вопрос приоритетов, а не тупых крутилок-костылей типа swappiness.

Это у тебя странная аргументация: Я сделал своп на HDD, и система виснет!

«Странная аргументация: я запустил процесс без yield(), и система виснет! Так не запускай процессы без yield(). Ты что, не знаешь, как многозадачность устроена?»

В отличие от 1985-го, сейчас мультиплексирование CPU не требует костылей в виде yield(). А вот мультиплексирование памяти под линуксом все еще требует обвешаться тонной костылей и точно знать, за какие красные флажки нельзя заходить. Иначе кирдык башка, зависон, reset.

Что за проблема? Что за патч?

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

Жрущий процесс не должен оказывать существенного влияния на отзывчивость других компонент системы

Допустим.

вне зависимости от деталей конфигурации системы подкачки

А вот тут есть варианты: своп на медленной подкачке или на быстрой. Ты выбрал своп на медленной подкачке, но виноват линукс, хотя линукс дал тебе выбор.

А вот тут есть варианты: своп на медленной подкачке или на быстрой.

Подкачка кому из них нужна: tail, который дожирает 9-й гигабайт памяти из 8-ми ГБ доступных в ОЗУ (лол), или терминалу, который и 100 метров не занимает?

9-й гигабайт памяти из 8-ми

ШТО

Подкачка кому из них нужна

Какое это имеет отношение к тому, что ты выбрал меленную подкачку вместо быстрой?