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

https://github.com/hakavlad/le9-patch/blob/main/experimental/le9fb_patches/le9fb-5.14.patch

post-factum ValdikSS

• Fatal IO error не воспроизводится, можно запускать десятки циклов с хвостами;
• новых побочек нет (с предыдущим le9fa бывали преждевременные убийства при стрессах);
• отлично работает как со свопом, так и без.

clean_min в сочетании с достаточным anon_min дает совершенно багоустойчивую конструкцию без побочек. Спрашивайте ответы.

Отправляйте в LKML.

post-factum ValdikSS

Во-первых, вышел le9fd, без заморозки и багов переваривающий даже

for i in {1..1000}; do (tail /dev/zero &); done

– быстрый запуск до тысячи хвостов - это невероятно!

https://github.com/hakavlad/le9-patch/blob/main/experimental/le9fd_patches/le9fd-5.14.patch

Маленькой новой побочкой остается нетерпимость к сбросу грязных страниц. Если нет резерва чистых и нет возможности свопить, то ООМ не будет ждать сборса грязных (если они есть). С другой стороны, это вариант более low-latency.

Вариант такой: причину багов искать где-то в GFP флагах.

https://elixir.bootlin.com/linux/latest/source/include/linux/gfp.h

https://www.kernel.org/doc/gorman/html/understand/understand009.html

1. История успеха https://github.com/hakavlad/prelockd/issues/9
2. 5.14.3.le9fd, for i in {1..100}; do (tail /dev/zero &); done - https://www.youtube.com/watch?v=tsnA6Mx-MpQ - есть лаги на записи, но в живом опыте лагов практически нет. Здесь быстро запущены 100 потоков tail /dev/zero, но машина не замёрзла.

[PATCH] mm/vmscan: add sysctl knobs for protecting the working set

https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv/

Отправил пока без бенчмарков и подробных объяснений.

https://lore.kernel.org/linux-mm/20211130201652.2218636d@mail.inbox.lv/

post-factum сообщения не доходят до linux-mm, хотя подписан. В чем может быть проблема?

Отправил пока без бенчмарков и подробных объяснений.

И поэтому не ожидай, что тебе кто-то напишет.

Я хз, возможно, у них что-то криво настроено.

В предыдущих сериях:

zram OOM behavior https://lore.kernel.org/all/CAA25o9TmsnR3T+CLk5LeRmXv3s8b719KrSU6C919cAu0YMKPkA@mail.gmail.com/

another allocation livelock with zram https://lore.kernel.org/all/CAA25o9T8cBhuFnesnxHDsv3PmV8tiHKoLz0dGQeUSCvtpBBv3A@mail.gmail.com/

[PATCH 0/2] Use up free swap space before reaching OOM kill https://lore.kernel.org/linux-mm/1357712474-27595-1-git-send-email-minchan@kernel.org/

[PATCH 0/2] Use up free swap space before reaching OOM kill https://lore.kernel.org/linux-mm/1357712474-27595-1-git-send-email-minchan@kernel.org/

zram, OOM, and speed of allocation https://lore.kernel.org/linux-mm/CAA25o9S5zpH_No+xgYuFSAKSRkQ=19Vf_aLgO1UWiajQxtjrpg@mail.gmail.com/

OOM at low page cache? https://lore.kernel.org/lkml/54C2C89C.8080002@gmail.com/

и еще бонус:

thrashing on file pages https://lore.kernel.org/linux-mm/CAA25o9TyPusF1Frn2a4OAco-DKFcskZVzy6S2JvhTANpm8cL7A@mail.gmail.com/

Есть идеи как это исправить (помимо отказа от введения ключей через Kconfig)? https://lore.kernel.org/all/202112010030.e6d9vIAL-lkp@intel.com/

На x86 и aarch64 такой проблемы не было.

Через #if defined.

http://ix.io/3GVk

Если захочешь учесть пожелания по sysctl, то вот можешь подсмотреть (база — next-20211203).

OOM killer – его наличие сомнительно само по себе.

Возвращаешь le9 в pf?

Пожалуйста, напомни, как задействовать фолиос в 516? Что-то включать надо? Как регулировать размер?

Я пока хз, но адаптировать никогда не рано/поздно.

Folios — это не что-то такое, что нужно/можно включать/выключать.

 #include <linux/printk.h>
 #include <linux/dax.h>
 #include <linux/psi.h>
+#include <linux/sysctl.h>

Это еще зачем? #include <linux/sysctl.h> уже там есть:

#include <linux/sysctl.h>
#include <linux/oom.h>
#include <linux/pagevec.h>
#include <linux/prefetch.h>
#include <linux/printk.h>
#include <linux/dax.h>
#include <linux/psi.h>

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/vmscan.c?h=next-20211203#n46

Упустил.

билд-тест проходил?

Успешно собрал с этим:

static struct ctl_table vm_workingset_table[] = {
	{
		.procname	= "anon_min_kbytes",
		.data		= &sysctl_anon_min_kbytes,
		.maxlen		= sizeof(unsigned long),
		.mode		= 0644,
		.proc_handler	= proc_doulongvec_minmax,
	},
	{
		.procname	= "clean_low_kbytes",
		.data		= &sysctl_clean_low_kbytes,
		.maxlen		= sizeof(unsigned long),
		.mode		= 0644,
		.proc_handler	= proc_doulongvec_minmax,
	},
	{
		.procname	= "clean_min_kbytes",
		.data		= &sysctl_clean_min_kbytes,
		.maxlen		= sizeof(unsigned long),
		.mode		= 0644,
		.proc_handler	= proc_doulongvec_minmax,
	},
	{ }
};

static int __init init_vm_workingset_table(void)
{
	register_sysctl_init("vm", vm_workingset_table);
	return 0;
}

early_initcall(init_vm_workingset_table);

Выглядит нормально?

Так же норм?

#ifdef CONFIG_SYSCTL
unsigned long sysctl_anon_min_kbytes __read_mostly = CONFIG_ANON_MIN_KBYTES;
unsigned long sysctl_clean_low_kbytes __read_mostly = CONFIG_CLEAN_LOW_KBYTES;
unsigned long sysctl_clean_min_kbytes __read_mostly = CONFIG_CLEAN_MIN_KBYTES;
#else
unsigned long sysctl_anon_min_kbytes __read_mostly = 0;
unsigned long sysctl_clean_low_kbytes __read_mostly = 0;
unsigned long sysctl_clean_min_kbytes __read_mostly = 0;
#endif

Да. А что, у тебя нет?

Зачем ifdef?

А как иначе?

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

Всё отлично билдится.

Что исправить это https://lore.kernel.org/all/202112010030.e6d9vIAL-lkp@intel.com/

Так проверять нужно не SYSCTL, а твои собственные ручки.

Есть случаи, в которых моих ручки есть, когда нет CONFIG_SYSCTL?

Я вижу один законный способ отсутствия моих ручек после принятия патча: не установлен SYSCTL. В прочих случаях ошибка сборки как раз и ДОЛЖНА произойти.

В чем я неправ?

Embedded.

А куда они денутся с embedded? Что заставит их исчезнуть? Чем embedded принципиально отличается в плане обработки или наличия стандартных ключей конфига?

Если есть возможность что-то выключить — его обязательно выключат.

и сборщик ядра не поленится выключить ещё :) а то железо нынче жырное, всё стерпит

http://ix.io/3GYY

+ можно устанавливать значения из bootloader’а.

sysctl и так уже давно из параметров ядра выставляются: sysctl.vm.dirty_bytes=

Думаю далее отправлять упрощенную версию и сосредоточиться на доказательствах главного - что защита кэша имеет значение. То есть думаю пока убрать anon кнопку и убрать Kconfig. dirty и swappiness не имеют же ключей конфига, пчм новые ключи должны это иметь?

mm-людям, кажется, с трудом даётся понимание смысла и важности le9. Нужно подробно разжёвывать все с множеством примеров.

BTW, сокращение DEF_PRIORITY уменьшает нагрузку на kswapd. По умолчанию (DEF_PRIORITY=12) tail /dev/zero грузит kswapd на 100%. При уменьшении DEF_PRIORITY до 8 нагрузка снижается до 70-80%.

Следующий вопрос: как находить memtotal, чтоб сделать кнопки типа vm.clean_min_ratio.

А если SYSCTL выключен?

Кстати, как его выключить? Не нашел выключатель в меню.

Следующий вопрос: как находить memtotal, чтоб сделать кнопки типа vm.clean_min_ratio.

post-factum

static void prepare_workingset_protection(pg_data_t *pgdat, struct scan_control *sc)
{
	if (sysctl_clean_low_kbytes || sysctl_clean_min_kbytes || sysctl_anon_min_kbytes) {
		unsigned long node_mem_total;
		unsigned long reclaimable_anon, reclaimable_file;
		unsigned long dirty, clean;
		struct sysinfo i;

		si_meminfo_node(&i, pgdat->node_id);
		node_mem_total = i.totalram;

		reclaimable_anon =
			node_page_state(pgdat, NR_ACTIVE_ANON) +
			node_page_state(pgdat, NR_INACTIVE_ANON) +
			node_page_state(pgdat, NR_ISOLATED_ANON);

		reclaimable_file =
			node_page_state(pgdat, NR_ACTIVE_FILE) +
			node_page_state(pgdat, NR_INACTIVE_FILE) +
			node_page_state(pgdat, NR_ISOLATED_FILE);

		dirty = node_page_state(pgdat, NR_FILE_DIRTY);

		/*
		 * node_page_state() sum can go out of sync since
		 * all the values are not read at once.
		 */
		if (likely(reclaimable_file > dirty))
			clean = reclaimable_file - dirty;
		else
			clean = 0;

		sc->anon_below_min = reclaimable_anon <
			node_mem_total * sysctl_anon_min_kbytes / 100;

		sc->clean_below_min = clean <
			node_mem_total * sysctl_clean_min_kbytes / 100;

		sc->clean_below_low = clean <
			node_mem_total * sysctl_clean_low_kbytes / 100;
	} else {
		sc->anon_below_min = 0;
		sc->clean_below_low = 0;
		sc->clean_below_min = 0;
	}
}

Это работает. Красивое? Здесь kbytes работают как ratio.

Еще вопрос: насколько велик оверхед от prepare_workingset_protection() и как его найти? Все-таки ж там выделяется память и идут некоторые вычисления.

post-factum следующий вопрос - реализация сосуществования ratio и kbytes кнопок, как в случае с dirty.

В pseudo filesystems.

ratio не нужно. Как и в случае с dirty. От слова совсем. Любой процент будет просто нерелевантен тому, что происходит в системе.

BTW, последний писк — вот это поверх v5.16-rc3?

Да. Вот результат тестирования: https://lore.kernel.org/linux-mm/20211202204229.5ed83f31@mail.inbox.lv/

anon ratio имеет смысл для меня.

Я нашел, что с anon_ratio = 10-20 нет багов - ни oops, ни вылетов браузера под некоторыми нагрузками с большим zram factor. - Как на машине с 2 гиг, так и с 12 гиг памяти.

Планирую так и делать: clean c kb, anon с ratio.

Еще думаю вообще избавиться от Kconfig. Да и нет традиции инициировать vm sysctl ключи через кконфиг. Ставить по дефолту нули или некоторые небольшие значение - это более стандартное решение. Это и кода меньше будет, и не будет дублирования текстов между Kconfig и vm.rst.

Как и в случае с dirty.

Каким должен быть дефолтный dirty_bytes, который устроит всех?

никаким, заменить его на допустимую латенси в долях секунды

Ну там замени. Мортон ждет твоих патчей.

пожалуй продолжу зоонаблюдать, а у себя замерил и прописал байтами