Linux 5.10

Ну, похоже что работает

Надо чтоб не просто работало, а работало без ошибок и падений, в том числе на моей хостовой.

Как тестировал работу? Насколько эффективно удерживается мягкий порог при стрессах?

когда падает ниже low, тогда валим в ноль.

имеешь в виду нище min?

Ты — мой QA/QE, а не наоборот ☺.

Да.

nr[lru] = scan / 8;

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

Уменьшаем число страниц, восстановленных из Active(file).

nr[lru] = scan / 64; - при своппинге порог держится, Active(file) уменьшается только при SwapFree = 0.

nr[lru] = scan / 1000; - работает почти как жесткая защита, то есть как nr[lru] = 0;.

Есть кейс, когда даже очень мягкая (scan / 2) защита дает Fatal IO error: большой zram disksize + сжатие несжимаемых данных. Тогда даже с мягчайшим фактором падает, в отличие от ванили. А у тебя в последней версии жесткость защиты только нарастает.

BTW, каков твой конфиг свопа надесктопе? используешь ли zram?

Интересные наблюдения. Истина где-то рядом.

Active(file) держится в сотке при своппинге, и прижимается к нулю при исчерпании свопа

При исчерпании именно свопа или вообще доступной памяти?

При обнулении SwapFree начинается восстановление из Active(file). То есть есть куда свопить - мягкая защита работает. Некуда свопить (своп переполнился или не смонтирован) - при нехватке памяти Active(file) уменьшается вместе с доступной памятью.

Мягкая защита (без жесткой) в сочетании с юзерспейсным киллером сейчас кажется лучшим вариантом.

Как тогда объяснить причину ошибки «Fatal IO error 11 (Ресурс временно недоступен)»?

Откуда ж мне знать. Тайна сия велика. Эта ошибка является практически единственной проблемой теперь.

На десктопе у меня вообще нет надобности в этом патче, на самом деле, потому как 32 GiB ОЗУ. Есть zswap, правда.

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

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

В shrink_node() есть такие строчки:

	/*
	 * Prevent the reclaimer from falling into the cache trap: as
	 * cache pages start out inactive, every cache fault will tip
	 * the scan balance towards the file LRU.  And as the file LRU
	 * shrinks, so does the window for rotation from references.
	 * This means we have a runaway feedback loop where a tiny
	 * thrashing file LRU becomes infinitely more attractive than
	 * anon pages.  Try to detect this based on file LRU size.
	 */
	if (!cgroup_reclaim(sc)) {
		unsigned long total_high_wmark = 0;
		unsigned long free, anon;
		int z;

		free = sum_zone_node_page_state(pgdat->node_id, NR_FREE_PAGES);
		file = node_page_state(pgdat, NR_ACTIVE_FILE) +
			   node_page_state(pgdat, NR_INACTIVE_FILE);

		for (z = 0; z < MAX_NR_ZONES; z++) {
			struct zone *zone = &pgdat->node_zones[z];
			if (!managed_zone(zone))
				continue;

			total_high_wmark += high_wmark_pages(zone);
		}

		/*
		 * Consider anon: if that's low too, this isn't a
		 * runaway file reclaim problem, but rather just
		 * extreme pressure. Reclaim as per usual then.
		 */
		anon = node_page_state(pgdat, NR_INACTIVE_ANON);

		sc->file_is_tiny =
			file + free <= total_high_wmark &&
			!(sc->may_deactivate & DEACTIVATE_ANON) &&
			anon >> sc->priority;
	}

Обратите внимание на file_is_tiny. Оно зависит от (внезапно, и какого чёрта вообще) от суммы high watermark’ов всех зон. В моём случае это около 130 МиБ по умолчанию, кстати.

Так вот, потом в том же get_scan_count(), который мы тут сообща насилуем, есть условие:

	/*
	 * If the system is almost out of file pages, force-scan anon.
	 */
	if (sc->file_is_tiny) {
		scan_balance = SCAN_ANON;
		goto out;
	} 

А теперь внимание вопрос: что мешает поменять условие для file_is_tiny, чтобы добиться того же, только с менее идиотскими правками в коде и (частично) отвязав его от watermark’ов?

Например, так (псевдокод, не пытайтесь это компилить):

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c017f44960f6..1c2661a49647 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2788,7 +2788,8 @@ static void shrink_node(pg_data_t *pgdat, struct scan_control *sc)
 		anon = node_page_state(pgdat, NR_INACTIVE_ANON);
 
 		sc->file_is_tiny =
-			file + free <= total_high_wmark &&
+			((file + free <= total_high_wmark) ||
+			 K(file) <= sysctl_unevictable_file_kbytes) &&
 			!(sc->may_deactivate & DEACTIVATE_ANON) &&
 			anon >> sc->priority;
 	}

некоторые VPS довольно стеснённые в ресурсах

Простейшим решением может быть earlyoom.

Имел я в виду юзерспейсные костыли.

Играл с факторами.

4 - безопасен, но эффективен. 2 - недостаточно эффективен. С большими порогами возможны падения при специальных стрессах.

Вот безопасный дефолт: min=0, low=200000, factor=4.

https://paste.rs/OLd.diff

А вот так не работает, зря я выше пыхтел.

Что это? Как работает?

Ты же знаешь, что обозначает выражение «не работает»? Или мне просто ответить «никак»?

Я тут снова смотрю на тот патч, который в Chromium OS. Вот то, что в свежей ветке. Мне интересно, почему там !mem_cgroup_disabled(), что будет, если убрать inactive, и зачем условие sc->gfp_mask & __GFP_IO.

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

Да пока некогда, как раз делаю окончательный безопасный патч.

Да пока некогда, как раз делаю окончательный безопасный патч.

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

А теперь внимание вопрос: что мешает поменять условие для file_is_tiny, чтобы добиться того же, только с менее идиотскими правками в коде и (частично) отвязав его от watermark’ов?

scan_balance = SCAN_ANON && goto out не приводит к nl[lru] = 0, чтобы привело, должно быть scan_balance = SCAN_FILE:

// из mm/vmscan.c
case SCAN_FILE:
case SCAN_ANON:
	/* Scan one type exclusively */
	if ((scan_balance == SCAN_FILE) != file)
	   scan = 0;

Откуда ж мне знать. Тайна сия велика. Эта ошибка является практически единственной проблемой теперь.

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

Непонятно вот что: в Chromium OS тупо пропускают часть действий. Отключают «Scan types proportional to swappiness and their relative recent reclaim efficiency». Не понимаю, каков конечный результат.

Угу, я тоже не очень ☹.

Можно вообще оставить только это:

#if defined(CONFIG_UNEVICTABLE_ACTIVEFILE)
		if (lru == LRU_ACTIVE_FILE) {
			unsigned long kib_active_file_now = K(global_node_page_state(NR_ACTIVE_FILE));

			if (kib_active_file_now <= sysctl_active_file_low_kib) {
				nr[lru] = scan / 4;
				continue;
			}
		}
#endif

CONFIG_PROTECT_ACTIVE_FILE
CONFIG_PROTECT_ACTIVE_FILE_LOW_KBYTES
vm.active_file_low_kib=200000

Что это даст:

• одна ручка, безопасно дающая улучшение отзывчивости при своппинге. Именно этот эффект мне кажется наиболее интересным и полезным. В такой конфигурации не страшно поставлять ядро с таким патчем по умолчанию.

Мне не очень нравится то, что на компьютерах с 512МБ-1ГБ ОЗУ будет такой же резерв

Что насчет vm.active_file_low_kbytes=200000 без жесткого порога? При нехватке памяти порог уменьшается, однако при избытке свопа вполне держится на достаточном уровне, давая ощутимый эффект. Так что даже в коробке с 500М памяти не сильно навредит, или не навредит вовсе.

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

Да, пытаюсь воспроизвести ту самую ошибку.

+		.extra1		= &sysctl_unevictable_activefile_kbytes_min,
+		.extra2		= &long_max,

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

Насколько важны эти строки? Прошлые патчи обходились без них. Что они делают?

Мне не нравятся все эти константы и эвристики.

Тогда лучший вариант такой:

		if (NR_ACTIVE_FILE == lru) {
				nr[lru] = scan / 4;
				continue;
			}
		}

– мягко защищаем Active(file) без ограничений. Просто, эффективно, безопасно.

И что характерно, ошибка бывает через пару секунд после ООМ - доступной памяти уже много, Active(file) вырос с 1М до 20М, и тут происходит ЭТО. – Исследовал процесс под лупой с инервалом 0.1 сек.

Никто этот патч в здравом уме в дистрибутиве из коробки не будет поставлять

Даже в самом мягком варианте?

long_max ушёл уже, а остальное — sanity, чтобы не получилось так, что low < min из-за ошибки юзера.

чтобы не получилось так, что low < min из-за ошибки юзера

Я думаю это ненужно контролировать. Если min > low -жесткий порог пусть применяется.

Делать так:

if kib <= min:
    return 0
if kib <= low:
    return scan / 4

Думать полезно, да.

Испытал свой вариант патча https://abf.io/mikhailnov/kernel-5.10/blob/bcdf18427e/rosa-le9.diff#lc-146

Загрузил систему с mem=2G. Выключил свопы (swapoff -a). oomd нет. Забил память Хромиумом до 1.7 ГБ (по показаниям ванильного htop). Запускаю Firefox. Система встает колом, постепенно зависая намертво.

[user@rosa2019 ~]$ sudo sysctl -a | grep evict
vm.compact_unevictable_allowed = 1
vm.unevictable_activefile_kbytes_low = 153600
vm.unevictable_activefile_kbytes_min = 51200
[user@rosa2019 ~]$ uname -a
Linux rosa2019.1 5.10.2-generic-2rosa2019.1-x86_64 #1 SMP PREEMPT Wed Dec 23 23:16:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[user@rosa2019 ~]$ 

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

И, соответственно, oom killer не срабатывал, ошибок i/o не было.

А с моим текущим вариантом как работает?

http://ix.io/2JtY

А с моим текущим вариантом как работает? http://ix.io/2JtY

Собрал с ним без изменений. Работает! Запустил систему с mem=2G. Больше 1.6 ГБ из 1.9 ГБ не получается занять, oom killer очень активно прибивает вкладки Chromium и Firefox, в т.ч. и давно не использованные вкладки Chromium постепенно чикает. Я бы сказал, через чур агрессивно. Странно. dmesg: https://clbin.com/kjMIm

[user@rosa2019 ~]$ sudo sysctl -a | grep evictable
vm.compact_unevictable_allowed = 1
vm.unevictable_activefile_kbytes_low = 524288
vm.unevictable_activefile_kbytes_min = 262144
[user@rosa2019 ~]$ uname -a
Linux rosa2019.1 5.10.2-generic-3rosa2019.1-x86_64 #1 SMP PREEMPT Fri Dec 25 12:31:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[Пт дек 25 17:21:07 2020] xfce4-panel invoked oom-killer: gfp_mask=0x400cc0(GFP_KERNEL_ACCOUNT), order=0, oom_score_adj=0

Вот это лишнее. У вкладок Хромиума же должен стоять высокий приоритет убивания oom killer’ом, интересно, почему полезло убивать xfce4-panel, наверное, потому что она попыталась в неудачный момент выделить память? (впрочем, ее убийство заметил только в dmesg, наверное, автоматически перезапустилась)

hakavlad

А как будет вести себя в сочетании с юзерспейсным oomd (erlyoom, nohang и т.д.)? Насколько хорошо oomd сможет успевать убивать выжирающий память процесс заранее, чтобы под раздачу освирипевшего oom killer’a не попала, например, xfce4-panel?

mem=2G. Больше 1.6 ГБ из 1.9 ГБ не получается занять, oom killer очень активно прибивает

Можешь прижать ручки вниз раза в 2–3, я дефолтные значения выбирал исходя из того, что 2 ГиБ мало у кого есть.

Хотя, можно и 128/256 сделать, хз.

Занизил ручки. В двух вариантах

1. vm.unevictable_activefile_kbytes_low=100000, vm.unevictable_activefile_kbytes_min=51000

2. vm.unevictable_activefile_kbytes_low=200000, vm.unevictable_activefile_kbytes_min=100000

(числа от балды)

поведение следующее и примерно одинаковое в обоих вариантах:

хромиум с кучей вкладок не занимается больше 1.6-1.65 ГБ, а запуск Firefox рядом с ним приводит к тому, что курсор мыши двигается, но с отрисовкой окон проблемы, система почти зависает, мышь двигается, что-то сделать можно попытаться, но толку от такого мало. OOM Killer не триггерится.

Не очень понимаю, почему так. Что-то вроде того, что, если в ручке выставлено памяти >= чем запрашивает процесс, то oom killer начинает свирептствовать, иначе толку почти нет.

Что-то вроде того, что, если в ручке выставлено памяти >= чем запрашивает процесс, то oom killer начинает свирептствовать, иначе толку почти нет.

Но это не объясняет, как под раздачу попал xfce4-panel, он почти наверняка не пытался занять >= памяти, чем указано в ручке.

Как меняется поведение, если сделать low == min?

Панель по-хорошему просто должна иметь негативный OOM score. Возможно, есть какой-то демон, который может рулить скорами автоматически как юзер укажет. Типа https://github.com/bplotnick/oomscored

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

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

Нет, стоп, xfce4-panel у тебя жива. Грепай по «Killed process». А то сообщение «invoked oom-killer» — это просто в контексте какого процесса OOM killer вызывается. Там у тебя везде браузер килляется.

Нет, стоп, xfce4-panel у тебя жива. Грепай по «Killed process». А то сообщение «invoked oom-killer» — это просто в контексте какого процесса OOM killer вызывается. Там у тебя везде браузер килляется.

понятно, проглядел, спасибо

Как меняется поведение, если сделать low == min?

Оба по 51000 - система подвисла, оба по 150000 - меньше подвисла, потом OOM Killer соизволил начать работать. Запуск stress --vm 1 --vm-bytes 512M --vm-keep четко триггерит OOM Killer, который убивает Chromium ([Пт дек 25 19:58:46 2020] stress invoked oom-killer: gfp_mask=0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0).

Вот это лишнее. У вкладок Хромиума же должен стоять высокий приоритет убивания oom killer’ом, интересно, почему полезло убивать xfce4-panel

Кто вызвал киллера не всегда совпадает с тем кого киллер убьет. Смотри:

[Пт дек 25 17:21:31 2020] xfce4-panel invoked oom-killer: gfp_mask=0x100cc0(GFP_USER), order=0, oom_score_adj=0

А в итоге:

[Пт дек 25 17:21:31 2020] Out of memory: Killed process 5535 (chrome) total-vm:9782648kB, anon-rss:103020kB, file-rss:7088kB, shmem-rss:4524kB, UID:1000 pgtables:1192kB oom_score_adj:300

Так что все в порядке.

Собрал с ним без изменений. Работает!

Это и логично, жесткий порог-то большой. Итересно, что на твоей машине нет ошибок. У меня в аналогичном опыте падала сессия с известной ошибкой.