Linux 5.10

Но это не объясняет, как под раздачу попал xfce4-panel

Вызвать киллера может кто угодно, но прибивается тот, у кого больший скор. Вызвавший киллера прибивается только при vm.oom_kill_allocating_task=1. Смотри не кто вызвал, а кто Killed.

Проблема в том, что oom хорошо срабатывает и предотвращает зависание, если память начинает требоваться процессу, не являющимся браузером (с более низким приоритетом убивания), а вот если идет конкуренция вкладок браузера и браузеров, то зависание нормально не предотвращается.

С одной стороны да, но с другой - а если она потечет, ее что, не убивать?

Так мы и не -1000 oom_score_adj ставим, а -200, например. То есть будет убита, но только при заметной утечке.

В Федоре earlyoom защищает по умолчанию важные процессы (ставит скор -300): dnf, Xorg, Xwayland, dnf, gnome-shell etc.

Прямо сейчас обсуждается возможность вкл systemd-oomd в Федоре, хотя у последнего даже стабильного релиза не было.

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

У меня в ВМ все работало, вкладки падали с порогом 200М.

У меня в ВМ все работало, вкладки падали с порогом 200М.

Что делал, чтобы вкладки начали падать?

Возможно, есть какой-то демон, который может рулить скорами автоматически как юзер укажет

earlyoom и nohang.

У nohang есть готовый десктопный конфиг с защитой WM и прочих компонентов DE и иксов https://github.com/hakavlad/nohang/blob/master/conf/nohang/nohang-desktop.conf.in - см 7. Customize victim selection: adjusting badness of processes.

Что делал, чтобы вкладки начали падать?

Рычал и двигал тазом да ничего особого вроде, открывал страницы просто. Конечно, вкладки падали не особо быстро. Юзерспейсные киллеры в этом плане удобнее.

да ничего особого вроде, открывал страницы просто. Конечно, вкладки падали не особо быстро. Юзерспейсные киллеры в этом плане удобнее.

А ничего из фоновых процессов не рычало и не двигало тазом? В dmesg кто был записан как триггернувший oom killer?

Не обращал внимания, но вкладки точно убивались.

Сделал ядро с конфигурабельной жесткостью мягкого порога, опубликую в течение суток.

Пришла странная идея сделать юзерспейсный генератор энтропии для OOM killer’a. Сделал так:

/* Based on https://stackoverflow.com/a/40407833
 * gcc -g -o oomk-entropyd oomk-entropyd.c
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int _alloc() {
	char *data;
	int bytes = (1024*1024*10);
	data = (char *) malloc(bytes);
	for(int i=0; i < bytes; i++){
		data[i] = (char) rand();
		// ./oomk-entropyd | dd of=result status=progress
		//printf("%c",data[i]);
	}
	free(data);
}

int main() {
	for (;;) {
		_alloc();
		sleep (15);
	}
}

Эффекта не возымело.

Попробовал подольше поработать с http://ix.io/2JtY + vm.unevictable_activefile_kbytes_min = 256000 и vm.unevictable_activefile_kbytes_low = 512000, после пары минут оказались прибиты почти все вкладки браузера, несмотря на то, что к ним не обращался, скрин: https://imgur.com/a/Aue5iF8. Это неюзабельно в общем.

Может, потому, что inactive не защищается?

mikhailnov post-factum Патч с реализацией мягкой защиты Active(file), с тремя крутилками. В настройках по умолчанию побочек не выявлено, в отличие от всех других вариантов. По умолчанию жесткая защита отключена, а мягкая соответственно действует весьма мягко, но ощутимо положительно при своппинге.

https://github.com/hakavlad/le9-patch/blob/main/le9aa1-5.10.patch

Кажись, я немного накосячил таки.

А если так: http://ix.io/2JCp ?

/cc hakavlad

tl;dr: в soft-режиме reclaim забирает максимум SWAP_CLUSTER_MAX (с учётом приоритета reclaim’а).

А что такое «мягкая» и «жесткая» защиты?

Жесткая защита - как в старых le9g/h/i патчах - установка нерушимого порога (возврат 0 вместо scan).

Мягкая защита есть замедление вытеснения страниц путем деления scan на vm.active_file_low_rigidity. Чем выше последний коэффициент, тем ближе мягкая защита к жесткой. Без свопа (и при исчерпании свопа) мягкая защита не действует и объем Active(file) может уйти почти в ноль. С мягкой защитой порог не держится на заданном уровне, но и не падает в ноль. По умоллчанию scan в мягкой защите делится на 4 - это дает эффект без побочек.

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

Собрал ядро без этого:

		switch (scan_balance) {
		case SCAN_EQUAL:
			/* Scan lists relative to size */
			break;
		case SCAN_FRACT:
			/*
			 * Scan types proportional to swappiness and
			 * their relative recent reclaim efficiency.
			 * Make sure we don't miss the last page on
			 * the offlined memory cgroups because of a
			 * round-off error.
			 */
			scan = mem_cgroup_online(memcg) ?
			       div64_u64(scan * fraction[file], denominator) :
			       DIV64_U64_ROUND_UP(scan * fraction[file],
						  denominator);
			break;
		case SCAN_FILE:
		case SCAN_ANON:
			/* Scan one type exclusively */
			if ((scan_balance == SCAN_FILE) != file)
				scan = 0;
			break;
		default:
			/* Look ma, no brain */
			BUG();
		}

Итог: приход ядерного киллера СИЛЬНО замедлился и даже с жестким файловым резервом киллер приходил после периода зависания. Тот самый баг таки удалось воспроизвести с этим ядром в том числе.

Ну, выбрасывать рандомные куски кода — такое себе занятие.

Возьми то, что я слал выше, http://ix.io/2JCp, установи min в 0, и получишь мягкую защиту.

Я бы не делил scan на что попало. Так теряется приоритет, и, похоже, там есть разумное ограничение в виде SWAP_CLUSTER_MAX на то, насколько маленьким может быть шаг reclaim’а.

Я бы не делил scan на что попало. Так теряется приоритет

Так, с учетом округления, вообще непонятно что получается

Ядро с http://ix.io/2JCp уже собираю

Ошибка I/O у тебя остается? Если нет, куда она делась?

С мягкой защитой порог не держится на заданном уровне, но и не падает в ноль

А какого ожидаемое поведение при отсутствии свопа?

Если SwapFree > 0:

• Значит есть куда вытеснять анонимку - и анонимка вытесняется в своп для освобождения доступной памяти под Active(file).

Если SwapFree = 0 (своп наполнен или не смонтирован):

• Active(file) начинает падать до нуля, защита снимается и соответственно побочек нет.

А какого ожидаемое поведение при НАЛИЧИИ свопа?

Уменьшение давления io и memory при своппинге без Fatal IO error.

Запилите новость про Ruby 3.0.0

https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/

Кыш.

Ошибка I/O у тебя остается? Если нет, куда она делась?

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

не кукарекай тут, мразь

А если так: http://ix.io/2JCp ?

Изменений не заметил. mem=2G, swapoff -a, забил память Хромиумом, открыл Firefox, oom killer прибил сразу много вкладок Хромиума на дефолтах и не прибил ничего при 50000 и 10000 в sysctl. Но, кажется, я проверяю не тот сценарий, на который рассчитан патч.

Вали уже.

Мы тут о disk thrashing, а не о том, что OOM делает свою работу. И на дефолты не равняйся, кстати, я тебе уже выше говорил, что для 2G они не подходят. Очевидно, что OOM придёт намного раньше, если ты 25% резервируешь тупо на file pages…

Это понятно. Я-то пытаюсь функционально толк от патч увидеть. 2 ГБ просто проще забить, чем мои родные 6 ГБ. disk thrashing, может, и снижен, но десктоп от этого не стал принципиально более юзабельным. Может, при этом по ssh остается возможность нормально соединиться, не проверял, если да, то полезно.

Толк в том, что при активном своппинге и свопе на zram система остается юзабельной (демо кидал выше - можно играть под стрессами). Для этого даже жесткая защита не нужна.

А для выполнения корректирующих действий при исчерпании и доступной, и свопа лучше подходят юзерспейсные киллеры - и сигнал мягче (SIGTERM сначала), и кастомизация выбора жертвы удобнее и гибче.

Патч дает то, чего не дают юзерспейсные киллеры - улучшение отзывчивости при интенсивном своппинге.

А вызывать корректирующее действие (в виде отправки сигналов) и юзерспейсные могут, без побочек.

Спасибо.

Значит есть куда вытеснять анонимку - и анонимка вытесняется в своп для освобождения доступной памяти под Active(file).

А как код в патче приводит к такому эффекту?

			if (kib_active_file_now <= sysctl_active_file_low_kbytes) {
				if (sysctl_active_file_low_rigidity >= 2) {
					nr[lru] = scan / sysctl_active_file_low_rigidity;
					continue;
				}
			}

					nr[lru] = scan / sysctl_active_file_low_rigidity;

– выселение активных файловых происходит с меньшим приоритетом, но оно таки не запрещено совсем.

Так тебе zram/zswap больше нужен в этом случае.

А, понял. Недавно проснулся, туплю.

что мешает поменять условие для file_is_tiny

Ждем готового патча.

Так тебе zram/zswap больше нужен в этом случае.

В чем разница между отсутствием свободной памяти+свопа без дискового свопа и zram и им же с zram, когда без zram занят? В том, что zram для vmscan.c все равно своп, в который будут reclaim-иться страницы и потом возвращаться обратно, тратя лишние ресурсы на перегонку туда-сюда бестолку?

тратя лишние ресурсы на перегонку туда-сюда бестолку?

Не бестолку, с толком - со свопом можно переваривать больший задачи, которые не помещаются в память без свопа. А со своп на zram это можно делать еще и быстро. А со свопом на zram и le9 - еще и без потери отзывчивости.

Ну и еще раз, только факты, вместо тысячи слов: https://youtu.be/c5bAOJkX_uc

потом возвращаться обратно, тратя лишние ресурсы на перегонку туда-сюда

Забавный факт: сжать гигабайт в свопе на zram можно быстрее, чем засвопить на диск.

У post-factum в http://ix.io/2JCp есть защита от установки _min больше чем _low:

+.extra1 = &zero_ul,
+.extra2 = &sysctl_unevictable_activefile_kbytes_low,

думаю, это стоит и в le9aa1-5.10.patch включить

Можно просто указать в документации, что если min >= low, то применяется жесткая защита. И код будет проще.

Все равно не понимаю, в чем разница в отзывчивости без дискового свопа, но с zram и без zram, если нагрузить систему настолько, сколько влезет? Понятно, что с zram влезет больше, но отзывчивость тут при чем? Видео пересмотрел, ответ на этот вопрос понятен не стал. Вот что бы было, если бы в тесте из видео не были включены ни zram, ни дисковый своп? Просто бы меньше копий tail запустил бы, а отзывчивость осталась бы той же самой?

Можно просто указать в документации, что если min >= low, то применяется жесткая защита. И код будет проще.

В принципе да. В патче http://ix.io/2JCp производятся сравнения двух величин, поэтому там важно, чтобы одно было больше другого, а в le9aa1-5.10.patch просто разные действий выполняются, там это не важно, просто min и low логически местами поменяются как бы.

Объясни, пожалуйста, как работает low_scan_granularity = SWAP_CLUSTER_MAX >> sc->priority;?

Я уже пробовал, говно получилось почему-то ☺.

zram нужен только когда нет свопа на диске. Когда он есть, zram лучше заменить на zswap. Выигрыш в обоих случаях в том, что сжимать данные в памяти намного быстрее, чем делать реальный I/O.

tl;dr: когда active_files меньше low, но больше min, то reclaim всё равно происходит, только не на полную катушку, а на минимально допустимое значение.

Более развёрнуто: в апстримном коде reclaim часто ограничивается не до нуля, а до минимального значения SWAP_CLUSTER_MAX. Без подглядывания в код могу по памяти сказать, что оно равно 32. Сдвиг на sc->priority нужен потому, что ранее значение scan (которое уже учитывает SWAP_CLUSTER_MAX) тоже безусловно сдвигается на значение приоритета. Поэтому если active_files падает ниже low, но для reclaim’а запрошено больше, чем можно минимально разрешить, то reclaim насильно прижимается к этому минимальному значению.

zram нужен только когда нет свопа на диске. Когда он есть, zram лучше заменить на zswap.

А чем zswap настолько лучше zram?

В свое время не пробовал zswap, т.к. неправильно понял, как он работает, это давно было. zram работает хорошо. Обычно применяю zram + дисковый своп. По идее zswap должен меньше лишних действий выполнять.

Если их оба включить одновременно, то zswap будет писать в zram, или он умнее? По идее скрипты включения zram должны писать 0 в /sys/module/zswap/parameters/enabled?