Linux 5.10

Без подглядывания в код могу по памяти сказать, что оно равно 32

Его не увеличили до 256? https://lore.kernel.org/patchwork/patch/575962/

В 5.10 еще #define SWAP_CLUSTER_MAX 32UL

Что такое UL?

дек 27 19:05:48 PC kernel: [   2164]  1000  2164   213245   212186  1757184        0             0 tail
дек 27 19:05:48 PC kernel: [   2167]  1000  2167    88294    87183   749568        0             0 tail
дек 27 19:05:48 PC kernel: [   2168]  1000  2168     5330     4216    90112        0             0 tail
дек 27 19:05:48 PC kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-5.scope,task=tail,pid=2155,uid=1000
дек 27 19:05:48 PC kernel: Out of memory: Killed process 2155 (tail) total-vm:2163044kB, anon-rss:2157144kB, file-rss:1564kB, shmem-rss:0kB, UID:1000 pgtables:4272kB oom_score_adj:0
дек 27 19:05:48 PC kernel: Purging GPU memory, 0 pages freed, 0 pages still pinned, 2113 pages left available.
дек 27 19:05:48 PC kernel: Purging GPU memory, 0 pages freed, 0 pages still pinned, 2112 pages left available.
дек 27 19:05:49 PC kernel: oom_reaper: reaped process 2155 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
дек 27 19:05:49 PC kernel: Purging GPU memory, 0 pages freed, 0 pages still pinned, 2112 pages left available.
дек 27 19:05:49 PC kernel: Out of memory: Killed process 2158 (tail) total-vm:2311484kB, anon-rss:2305512kB, file-rss:1632kB, shmem-rss:0kB, UID:1000 pgtables:4564kB oom_score_adj:0
дек 27 19:05:49 PC kernel: oom_reaper: reaped process 2158 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
дек 27 19:05:49 PC kernel: Purging GPU memory, 0 pages freed, 0 pages still pinned, 5994 pages left available.
дек 27 19:05:49 PC kernel: Out of memory: Killed process 2160 (tail) total-vm:1951840kB, anon-rss:1945944kB, file-rss:1556kB, shmem-rss:0kB, UID:1000 pgtables:3856kB oom_score_adj:0
дек 27 19:05:49 PC kernel: oom_reaper: reaped process 2160 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
дек 27 19:05:49 PC kernel: Purging GPU memory, 0 pages freed, 0 pages still pinned, 2112 pages left available.
дек 27 19:05:49 PC kernel: Out of memory: Killed process 2159 (tail) total-vm:1919168kB, anon-rss:1913468kB, file-rss:1560kB, shmem-rss:0kB, UID:1000 pgtables:3800kB oom_score_adj:0
дек 27 19:05:49 PC clock-applet[1406]: clock-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:50 PC kernel: oom_reaper: reaped process 2159 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
дек 27 19:05:50 PC kernel: Purging GPU memory, 0 pages freed, 0 pages still pinned, 2112 pages left available.
дек 27 19:05:50 PC kernel: Out of memory: Killed process 2164 (tail) total-vm:2118172kB, anon-rss:2112264kB, file-rss:1568kB, shmem-rss:0kB, UID:1000 pgtables:4192kB oom_score_adj:0
дек 27 19:05:50 PC kernel: oom_reaper: reaped process 2164 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
дек 27 19:05:49 PC polkitd(authority=local)[839]: Unregistered Authentication Agent for unix-session:5 (system bus name :1.25, object path /org/mate/PolicyKit1/AuthenticationAgent, locale ru_RU.UTF-8) (disconnec
дек 27 19:05:50 PC org.a11y.atspi.Registry[1216]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
дек 27 19:05:50 PC org.a11y.atspi.Registry[1216]:       after 469 requests (469 known processed) with 0 events remaining.
дек 27 19:05:49 PC unknown[1311]: notification-area-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:49 PC unknown[1325]: mate-brightness-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:49 PC unknown[1331]: mate-sensors-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:49 PC unknown[1323]: mate-multiload-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:50 PC lightdm[1152]: pam_unix(lightdm:session): session closed for user user
дек 27 19:05:49 PC unknown[1298]: wnck-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:49 PC unknown[1447]: mate-system-monitor: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 27 19:05:51 PC systemd-logind[748]: Removed session 5.
дек 27 19:05:51 PC lightdm[1093]: session_get_login1_session_id: assertion 'session != NULL' failed
дек 27 19:05:51 PC kernel: nouveau 0000:01:00.0: Enabling HDA controller
дек 27 19:05:55 PC lightdm[2186]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
дек 27 19:05:55 PC systemd[1]: Created slice User Slice of lightdm.

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

Что такое UL?

Не знаю, самому интересно.

post-factum, а приоритет - это приоритет свопа, который покажет swapon -s или что?

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

zswap не сжимает несжимаемое и пишет его на диск. Но если данные сжимаются хорошо, то они сжимаются и остаются в памяти.

Если их оба включить одновременно, то zswap будет писать в zram, или он умнее?

КМК, да, будет писать, поэтому учитывая вышесказанное, толку от такой связки 0.

unsigned long

приоритет

Если ты о sc->priority, то нет, это приоритет reclaim’а.

А что в итоге означает 32 unsigned long в этом контексте?

#if defined(CONFIG_PROTECT_ACTIVE_FILE)
		unsigned long kib_active_file_now = K(
			global_node_page_state(NR_ACTIVE_FILE));

		if (kib_active_file_now <= sysctl_active_file_min_kbytes) {
			nr[lru] = 0;
			continue;
		}

		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;
			}
		}
#endif

Жесткий резерв 500М. Итог:

• https://i.ibb.co/n88JGcc/2020-12-27-19-10-47.png
• https://i.ibb.co/jgmNBHy/2020-12-27-19-05-18.png

IO errors меньше, длинные стрессы возможны, но ошибки все равно есть.

Если по синтаксису, то это простое приведение типов. Сишечка бывает странная, да.

Если по сути, то в моём патче это значение есть максимальный шаг reclaim’a, когда active_files опускается ниже low, но ещё не min. На практике это означает, что реальное значение active_pages не опустится ниже min, а будет плавать немного выше. Насколько выше — зависит от конкретных порогов и интенсивности насилования памяти.

Насколько выше — зависит от конкретных порогов и интенсивности насилования памяти.

Не ясно как раз то, какие именно значения это все примет? Например, на системе с 2 ГБ ОЗУ + 2 ГБ дискового свопа + zswap low_scan_granularity чему будет равно?

Кажется, я глупость спросил, ведь SWAP_CLUSTER_MAX не зависит от конфигурации свопа. В общем надо разбираться, как задается sc->priority.

Мутно задаётся. Кое-что проясняют комментарии в коде:

	/* Scan (total_size >> priority) pages at once */
	s8 priority; 

…

 * @priority is sc->priority, we take the number of objects and >> by priority
 * in order to get the scan target.

…

/*
 * The "priority" of VM scanning is how much of the queues we will scan in one
 * go. A value of 12 for DEF_PRIORITY implies that we will scan 1/4096th of the
 * queues ("queue_length >> 12") during an aging round.
 */
#define DEF_PRIORITY 12

…

	BUILD_BUG_ON(DEF_PRIORITY > S8_MAX); 

…

 * The vmscan logic considers these special priorities:
 *
 * prio == DEF_PRIORITY (12): reclaimer starts with that value
 * prio <= DEF_PRIORITY - 2 : kswapd becomes somewhat overwhelmed
 * prio == 0                : close to OOM, kernel scans every page in an lru
 *
 * Any value in this range is acceptable for this tunable (i.e. from 12 to
 * 0).

И, похоже, он может только уменьшаться:

static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
					  struct scan_control *sc)
{ 
…
		/*
		 * If we're getting trouble reclaiming, start doing
		 * writepage even in laptop mode.
		 */
		if (sc->priority < DEF_PRIORITY - 2)
			sc->may_writepage = 1;
	} while (--sc->priority >= 0); 

…

static int balance_pgdat(pg_data_t *pgdat, int order, int highest_zoneidx)
{ 
…
		if (raise_priority || !nr_reclaimed)
			sc.priority--;
	} while (sc.priority >= 1); 

…

static int __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int order)
{ 
…
	if (node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages) {
		/*
		 * Free memory by calling shrink node with increasing
		 * priorities until we have enough memory freed.
		 */
		do {
			shrink_node(pgdat, &sc);
		} while (sc.nr_reclaimed < nr_pages && --sc.priority >= 0);
	} 

Т.е., IIUC, всё начинается с 12 (reclaim’ить 1/4096-ю) и кончается на нуле (reclaim’ить всё).

Кстати, поскольку приоритет находится в диапазоне [0..12], интересно бы было сделать в моём патче так:

unsigned long low_scan_granularity = (1UL << (DEF_PRIORITY - 1)) >> sc->priority;

Не хочешь попробовать? /cc hakavlad

Хотя я вангую, что в таком случае reclaim при min < X < low просто будет происходит агрессивней, поэтому оставляю SWAP_CLUSTER_MAX.

Не хочешь попробовать?

Сначала нужно придумать методику измерения результата не эмперически на глаз.

С приоритетом стало яснее, спасибо.

Сначала нужно придумать методику измерения результата не эмперически на глаз.

И еще надо бы придумать математически обоснованный алгоритм подбора значений min и low.

Опубликовал в репозиторий rosa2019.1 (и скоро опубликуется в contrib rosa2016.1) пока экспериментальное и не основное ядро 5.10 с этим патчем

https://abf.io/import/kernel-5.10/tree/905b60d3c27203308fcd9f627e444db99466e096

Стоит 50 и 100 МБ, еще по твоей наводке включил zswap из коробки, на нетбуке с 2 ГБ памяти и дисковым свопом погонял, намертво не зависло.

Позже это ядро должно стать основным в rosa2019.1 (R12+).

Сначала нужно придумать методику измерения результата

1. Логирование метрик PSI. psi2log поможет. https://github.com/hakavlad/nohang/blob/master/docs/psi2log.manpage.md

le9 снижает давление io, что детектится через psi2log.

2. Логирование уровней Active(file) под нагрузкой. mem2log есть, опубликую скоро.

3. glxgears поможет мониторить FPS.

le9 с ручками для настройки будет в Росе, верно?

если active_files падает ниже low, но для reclaim’а запрошено больше, чем можно минимально разрешить, то reclaim насильно прижимается к этому минимальному значению

Даже если поставить 1 страницу в виде верхней границы - защита будет очень мягкой. То есть если просто без делителя ограничить reclaim до 1 страницы - это весьма слабая защита. Если же установить 32 страницы снизу - это вообще дырявая защита.

Код примерно такой:

if scan > 1:
    nr[lru] = scan

Или я неправильно понял? Речь о том, чтоб в nr[lru] передавать не меньше 32 страниц?

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

Более развёрнуто: в апстримном коде reclaim часто ограничивается не до нуля, а до минимального значения SWAP_CLUSTER_MAX

Это будет очень, очень слабая защита.

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

			scan = lruvec_size - lruvec_size * protection /
				cgroup_size;

надо бы придумать математически обоснованный алгоритм подбора значений min и low.

Автор оригинального патча предложил это:

+To get an idea what value to use here for your workload(eg. xfce4 with idle
+terminals) to not disk thrash at all, run this::
+
+	$ echo 1 | sudo tee /proc/sys/vm/drop_caches; grep -F 'Active(file)' /proc/meminfo
+	1
+	Active(file):     203444 kB
+
+so, using vm.unevictable_activefile_kbytes=203444 would be a good idea here.
+(you can even add a `sleep` before the grep to get a slightly increased value,
+which might be useful if something is compiling in the background and you want
+to account for that too)

– https://github.com/hakavlad/le9-patch/blob/main/original_patches/le9h.patch#L68

На моем деб9 под легким стрессом и мягкой защитой Active(file) опускается до 50М, но гуй при этом еще жив.

При запуске файлоёмкой задачи AF до 200-250М поднимается при мягкой защите.

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

Я бы не делил scan на что попало

Все ОК с любыми значениями от 1 до 10000. Эффект колеблется от отсутствия защиты до эквивалента жесткой защиты. Никаких новых побочек не добавляется. С увеличением делителя и по мере ужесточения защиты в некоторых конфигурациях лишь растет риск получения Fatal IO error.

Способ с делением - весьма гибкий.

Пробовал вместо деления ставить возможность указания нижнего и верх порога. Если оба порога зафиксировать в 1 - будет достаточно слабая защита. Верхняя защита в 32 страницы - это никакая защита.

Таким образом, способ с целочисленным делением scan остается предпочтительным и наиболее гибким.

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

Система встает колом, постепенно зависая намертво.

vm.unevictable_activefile_kbytes_min = 51200

Не удивительно, ведь хотя бы 200М желательно для прихода киллера.

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

То есть мейнтейнеры ROSA Linux - больные на голову?

А как будет вести себя в сочетании с юзерспейсным oomd (erlyoom, nohang и т.д.)? Насколько хорошо oomd

Вопрос об oomd или вообще о сочетаемости юзерспейсных киллеров и le9?

В общем случае убивать будет тот, у кого задан выше порог.

le9 вполне совместим с киллерами.

Не больше 32 страниц.

На то она и слабая. Для reclaim’а будет предлагаться от 0 до 32 страниц, не более. Поэтому он таки будет весьма ограничен.

Никто не мешает выкрутить ручки, как хочется. А весь цимес изначально таки в жёсткой защите.

Да? (не утверждаю, но как бы спрашиваю)

Да, уже есть. Если не будет выявлено критичных проблем, во Fresh R12 / RED X5 / etc будет из коробки.

Само по себе значение Active(File) не говорит, скажем так, о функциональных проявлениях патча. hakavlad предложил следить за /proc/pressure/memory, это больше похоже на показатель, который может отразить функциональные свойства системы, скажем так. Представить связь /proc/pressure/memory с ощущениями от использования системы можно ощутить. Еще можно load average смотреть.

Не удивительно, ведь хотя бы 200М желательно для прихода киллера.

Приход киллера в его текущем виде нежелателен, т.к., когда он приходит, он стреляет во все стороны, прибивая пользовательские приложения в избыточном кол-ве. Поэтому тащить дефолт в 256 и 512 МБ в дистрибутив - надо быть действительно слегка больным на голову.

За идею с PSI спасибо, а показатели в /proc/pressure/memory пропорциональны ли скорости работы процессора, грубо говоря? Ведь там указано время, а значит, чем слабее процессор (и ниже производительность системы в целом), тем больше будут значения, а значит абсолютные значения из PSI можно сравнивать только в пределах одной машины (иное и не требуется, но были мысли, что их можно было бы как-то читать и на ходу что-то подкручивать из юзерспейса).

Тест связанный с io:

vm.active_file_low_rigidity=50
Peak values:  avg10  avg60 avg300
-----------  ------ ------ ------
some cpu       1.21   0.41   0.32
-----------  ------ ------ ------
some io        5.56   2.26   5.49
full io        5.29   2.15   4.97
-----------  ------ ------ ------
some memory   46.42  15.29   7.77
full memory   21.44   6.38   3.78

real    0m24,197s
user    0m0,057s
sys     0m16,736s

vm.active_file_low_rigidity=0
Peak values:  avg10  avg60 avg300
-----------  ------ ------ ------
some cpu       0.71   0.22   0.21
-----------  ------ ------ ------
some io       43.60  19.32  11.10
full io       39.69  17.77  10.33
-----------  ------ ------ ------
some memory   45.29  18.24   9.24
full memory   35.98  13.29   5.79

real    0m34,383s
user    0m0,063s
sys     0m13,768s

(раздувание списка результатом чтения из /usr/lib/chromium/chromium - читаем файл и в цикле добавляем в список, пока не будет убито юзерспейсн киллером) – ускорение и значительное снижение io

PSI отдельно оценивает каждый ресурс - io, cpu, mem - задержики доступа к ресурсам.

https://www.kernel.org/doc/html/latest/accounting/psi.html

https://facebookmicrosites.github.io/psi/docs/overview

Почему earlyoom в росе не включили?

Комплексное решение проблемы включает в себя три компонента:

• zram или zswap - ускорение своппинга, снижают давление io/mem в сравнении с дисковым свопом
• le9 - в общем-то тоже снижает давление io
• юзерспейсный киллер - мягкое,быстрое и гибкое выбор жертвы и завершение процессов, опционально с защитой важных для сессии

Я еще не успел изучить вопрос. Надо же не просто ctrl+c ctrl+v из федоры, а тщательно продумать конфиг, списки неубиваемых процессов, путей подправить, учесть KDE4. А почему не nohang?

С le9aa1 проблем быть не должно. Кстати фактор 4 слабоват все-таки. Может до 16-32 повысить хотя бы. Ну и мягкая защита на малопамятных машинах тоже не повредит, даже если в миллион порог выставить.

А почему не nohang?

Да пожалуйста, берите.

Просто в Федоре я сказал, что earlyoom проще и стабильнее, и рекомендовал его. nohang это таки комбайн. Готов консультировать по включению. nohang может быть интересен гуи уведомлениями и возможностью реакции на PSI. Хотя после вкл zram и le9 это может и не понадобится - давление в любом случае не будет критическим.

Начало Федоры: https://pagure.io/fedora-workstation/issue/98

Дефолтный конфиг earlyoom должен и вам подойти https://pagure.io/fedora-workstation/issue/119#comment-638366

Хотя после вкл zram и le9 это может и не понадобится

А после включения zswap+le9, а не zram?

Кстати, а в nohang уведомления до сих пор через выдирание переменных окружения из ps(1)?

Парсится /proc/pid/environ кажного процесса. Все это дело происходит в отдельном треде, и рождение уведомления не тормозит главный поток. Никаких зависимостей и доп скриптов. Только notify-send. ps не нужен.

Да как хотите. Но имхо zram популярнее у дистрибутивов. У Федоры, калькулейт и Garuda Linux - zram.

У Garuda Linux (индийская сборочка арча) nohang-desktop давно по умолчанию. И prelockd и memavaild тоже из коробки.

Remind me, please, why zram, not zswap?

См https://pagure.io/fedora-workstation/issue/98#comment-629620

там ничего внятного

а на днях открывал архив гуглодиска, и при чтении оного система начала тупить даже на ext4.

Ты так и не ответил что у тебя с грязными байтами. Зачем оставляешь дефолты?

В Chrome OS ставят background_ratio=1, помимо защиты filelist.

Вот новое демо: https://youtu.be/46PUMOxZ-mY

factor=32, fps хромает, но гуй жив и игра идет. На фоне 8 потоков tail /dev/zero.