Linux 5.10

Прелагаю дефолты сделать такими: 254M Active, 0 Inactive. Это хорошо работает и при нормальных нагрузках дает только плюсы.

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

Было бы неплохо

Feel free to implement, как говорится.

Таки да, неплохо б 5%, но не более 256М, например.

Я в сях не разбираюсь, если что.

5.10 – полет нормальный.

5.10.2 вышло

вар: добавить vm.unevictable_activefile_ratio

Никто этот патч в здравом уме в дистрибутиве из коробки не будет поставлять. А если компилить самому, то можно сконфигурить любое значение. Хоть 0. И потом безо всяких скриптов менять его через sysctl.conf при загрузке.

Данунах. Это как с dirty_ratio, когда по умолчанию оно может быть настолько большим при нынешних объёмах ОЗУ, что никакого смысла в нём нет.

Ну так каков план? с 256 включишь для нормального десктопа?

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

Я не включаю что-то для десктопа, я даю патч, который даёт пользователю возможность что-то изменить.

Зачем мне тестировать, если есть ты ☺. И потом, я когда разверну этот патч на своих серваках, и что-то пойдёт не так, вот тогда и протестирую.

по умолчанию

Никто не насилует того, кто применяет патч, билдить ядро с этой опцией.

В арч-репе pf-kernel с какими-то дефолтами ж поставляется. Юзеры обычно просто берут альтернативное ядро, потому что ожидают от альтернативы лучшей отзывчивости и производительности. Не у кажого доходят руки до тюнинга.

В арч-репе pf-kernel с какими-то дефолтами ж поставляется.

Да, эта репа для меня. То, что она доступна кому-то ещё, — случайность, и это не снимает ответственность в плане понимания происходящего.

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

Мне нет дела до таких юзеров. Такие юзеры юзают -zen или -lqx и не жужжат, там всё решают за них.

Как вам такое:

дек 22 03:13:42 PC kernel: [   3052]  1000  3052   346686    18478  1392640        0           300 chromium
дек 22 03:13:42 PC kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-9.scope,task=chromium,pid=2910,uid=1000
дек 22 03:13:42 PC kernel: Out of memory: Killed process 2910 (chromium) total-vm:1410952kB, anon-rss:24460kB, file-rss:72348kB, shmem-rss:388kB, UID:1000 pgtables:1468kB oom_score_adj:300
дек 22 03:13:42 PC kernel: oom_reaper: reaped process 2910 (chromium), now anon-rss:0kB, file-rss:0kB, shmem-rss:152kB
дек 22 03:13:44 PC org.a11y.atspi.Registry[1264]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
дек 22 03:13:44 PC org.a11y.atspi.Registry[1264]:       after 299 requests (299 known processed) with 0 events remaining.
дек 22 03:13:49 PC kernel: nouveau 0000:01:00.0: Enabling HDA controller
дек 22 03:13:45 PC polkitd(authority=local)[838]: Unregistered Authentication Agent for unix-session:9 (system bus name :1.25, object path /org/mate/PolicyKit1/AuthenticationAgent, locale ru_RU.UTF-8) (disconnec
дек 22 03:13:44 PC unknown[1352]: notification-area-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:44 PC unknown[1366]: mate-brightness-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:44 PC unknown[1368]: mate-sensors-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:44 PC unknown[1348]: wnck-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:44 PC unknown[1364]: mate-multiload-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:45 PC unknown[1440]: clock-applet: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:46 PC unknown[1488]: mate-system-monitor: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.
дек 22 03:13:52 PC kernel: MTP Main Sessio[2260]: segfault at 30 ip 0000000003a3a306 sp 00007febaabbc690 error 4 in Telegram[400000+568f000]
дек 22 03:13:52 PC kernel: Code: 24 28 8b 05 d4 69 6b 02 83 f8 ff 7c 16 0f b6 05 88 69 6b 02 84 c0 0f 84 d8 00 00 00 4c 8d 2d 81 69 6b 02 4d 8d 7d 30 4c 89 e9 <45> 8b 27 44 89 e5 45 89 e5 81 e5 ff ff ff 00 41 81
дек 22 03:13:52 PC stunnel[833]: LOG5[20]: Connection closed: 21507 byte(s) sent to TLS, 797346 byte(s) sent to socket
дек 22 03:13:56 PC lightdm[3123]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
дек 22 03:13:56 PC systemd[1]: Created slice User Slice of lightdm.

– le9pf с дефолтами в опыте А. Ташкинова (mem-4G и открытие вкладок). Не зависло, но упала сессия.

На самом деле le9 таит в себе огромный потенциал побочек.

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

упала сессия

А часовню тоже я?..

https://gitlab.com/post-factum/pf-kernel/-/tags/v5.10-pf2

Как тебе такое:

+#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_unevictable_activefile_kbytes) {
+				nr[lru] = scan / 8;  //  <== This
+				continue;
+			}
+		}
+#endif

Может ли это работать как мягкая защита?

#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 <= 320000) {
				nr[lru] = scan / 2;
				continue;
			}
			if (kib_active_file_now <= 160000) {
				nr[lru] = scan / 4;
				continue;
			}
			if (kib_active_file_now <= 80000) {
				nr[lru] = scan / 8;
				continue;
			}
		}
#endif

Это валидная конструкция?

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

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

Воспрос-то вот в чем: законно ли вообще так делить - возвращать дроби от scan, будет ли это работать как мягкая защита для activefile? Я вижу, что выше по функции для защиты спокойно применяются дроби:

			scan = lruvec_size - lruvec_size * protection /
				cgroup_size;

Там же целочисленное деление, что ему станется-то.

Удалось реализовать мягкую защиту:

MA: 59.9M (1.5%), AF: 96.9M (2.5%), IF: 0.5M (0.0%), SF: 842.7M
MA: 65.6M (1.7%), AF: 96.7M (2.5%), IF: 0.5M (0.0%), SF: 659.7M
MA: 70.2M (1.8%), AF: 95.7M (2.4%), IF: 0.4M (0.0%), SF: 491.6M
MA: 70.9M (1.8%), AF: 95.6M (2.4%), IF: 0.4M (0.0%), SF: 310.1M
MA: 73.1M (1.9%), AF: 95.4M (2.4%), IF: 0.4M (0.0%), SF: 95.2M
MA: 72.0M (1.8%), AF: 95.3M (2.4%), IF: 0.4M (0.0%), SF: 35.3M
MA: 72.2M (1.8%), AF: 95.3M (2.4%), IF: 0.4M (0.0%), SF: 10.1M
MA: 70.3M (1.8%), AF: 95.3M (2.4%), IF: 0.5M (0.0%), SF: 8.7M
MA: 70.6M (1.8%), AF: 95.3M (2.4%), IF: 0.4M (0.0%), SF: 8.2M
MA: 72.0M (1.8%), AF: 95.3M (2.4%), IF: 0.3M (0.0%), SF: 1.0M
MA: 8.1M (0.2%), AF: 7.0M (0.2%), IF: 0.0M (0.0%), SF: 0.0M  <==================
MA: 365.4M (9.3%), AF: 8.5M (0.2%), IF: 1.8M (0.0%), SF: 3021.9M
MA: 856.2M (21.7%), AF: 13.8M (0.4%), IF: 3.3M (0.1%), SF: 6200.2M
MA: 1178.7M (29.9%), AF: 18.2M (0.5%), IF: 4.4M (0.1%), SF: 10006.4M
MA: 1229.7M (31.2%), AF: 21.7M (0.5%), IF: 6.0M (0.2%), SF: 14386.1M
MA: 1278.0M (32.4%), AF: 26.4M (0.7%), IF: 7.1M (0.2%), SF: 18435.9M
MA: 1325.8M (33.6%), AF: 32.3M (0.8%), IF: 8.0M (0.2%), SF: 22605.8M
MA: 1465.7M (37.2%), AF: 36.2M (0.9%), IF: 9.4M (0.2%), SF: 26350.7M
MA: 3211.7M (81.5%), AF: 37.3M (0.9%), IF: 13.2M (0.3%), SF: 27208.6M

Active(file) держится в сотке при своппинге, и прижимается к нулю при исчерпании свопа. Ожидается, что такой алгоритм не будет давать побочек описанных выше в виде падения сессии и io err.

Что-то останется, даже если делить на сто. Схема такая:

#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_unevictable_activefile_kbytes) {
				nr[lru] = scan /
				sysctl_unevictable_inactivefile_kbytes;
				continue;
			}
		}
#endif

vm.unevictable_activefile_kbytes=300000
vm.unevictable_inactivefile_kbytes=100

vm.unevictable_inactivefile_kbytes=100 - здесь чем болше фактор, тем жестче защита.

И шо, мне ещё две ручки добавить, vm.sysctl_unevictable_{inactive,active}file_factor со значениями 0..100? Чтобы так:

nr[lru] = scan * (sysctl_unevictable_{inactive,active}file_factor / 100) 

Когда factor == 0, то nr[lru] будет падать в ноль, когда 100 — не будет вообще.

Я думал сделать так:

CONFIG_PROTECT_ACTIVEFILE
vm.activefile_divide_factor=100 - насколько агрессивно защищать объем vm.activefile_low_kbytes
vm.activefile_low_kbytes=200000 - мягкая защита
vm.activefile_min_kbytes=20000 - жесткая защита

Давай подумаем еще.

scan * (sysctl_unevictable_{inactive,active}file_factor / 100)

Прям так? С типами все в порядке, результат целочисленный?

Думаю юзерам не очень интересен резерв Inactive.

Завтра все сделаю.

Не, мне вообще не нравятся дополнительные ручки. Я тут подумал, и я бы factor таки не делал дополнительной ручкой. КМК, scan можно уменьшать автоматически пропорционально. Может, так:

nr[lru] = scan * kib_active_file_now / sysctl_unevictable_activefile_kbytes;

Здесь гарантированно kib_active_file_now <= sysctl_unevictable_activefile_kbytes просто потому, что оно под условием if’а, соответственно, чем меньше kib_active_file_now, тем сильнее прижимается scan. Можно сделать не линейно, а экспоненциально.

мне вообще не нравятся дополнительные ручки

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

Как говорилось выше, бывали проблемы с жесткой защитой - падения сессии в некоторых кейсах. Поэтому хочу оставить мягкую защиту и как минимум 2 ручки - activefile_low_kbytes и activefile_min_kbytes. Может позже захардкодить factor, после тестов, если удасться найти какое-то универсальное оптимальное значение.

nr[lru] = scan * kib_active_file_now / sysctl_unevictable_activefile_kbytes;

Вообще-то желаемым поведением при мягкой защите является возможность довольно прочно держать заданный порог пока есть запас SwapFree, и снимать защиту при невозможности дальнейшего вытеснения анона в своп - чтоб не было того самого Fatal IO error, см Linux 5.10 (комментарий). Здесь же, если kib_active_file_now будет чуть ниже sysctl_unevictable_activefile_kbytes, то защиты практически не будет - фактор будет чуть ниже, что практически не даст эффекта.

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

CONFIG_PROTECT_ACTIVEFILE

vm.activefile_low_kbytes=200000
vm.activefile_low_rigidity=100
vm.activefile_min_kbytes=20000

Если свести количество «крутилок» до минимально необходимого, будет проще тестировать всё на практике и получать реальные результаты.

Если свести количество «крутилок» до минимально необходимого

Три крутилки для activefile - это и есть мин необходимое. Простой алгоритм и достаточная минимальная гибкость. Каждая из трех имеет значение.

Думаю activefile_low_rigidity можно сделать в диапазое 1-8 с соответствующим диапазоном факторов 2^1 - 2^8.

https://paste.rs/GgX.diff

Вот так, например. Когда min < X < low, прижимаем scan линейно, когда падает ниже low, тогда валим в ноль.

https://paste.rs/aNR.diff

Немного подправленное в плане проверки значений sysctl и другой минорщины.

https://gitlab.com/post-factum/pf-kernel/-/commit/aebcd2e7db81c5c103a18dc567eaa7e2454ceeea

Ушёл билдить и смотреть, что получилось.

Ну, похоже что работает. hakavlad, ваше мнение очень важно для нас.

прижимается к нулю при исчерпании свопа

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

Fatal IO error 11 (Ресурс временно недоступен)

Это та ошибка, которую получает userspace программа при нехватке памяти, когда сработал le9? Какая-то странная ошибка, должна быть в явном виде ошибка отказа выделения памяти («Cannot allocate memory»), а не вот такое, мне кажется.

[ мысли вслух, поток сознания ]

В ядре есть:

enum scan_balance {
	SCAN_EQUAL,
	SCAN_FRACT,
	SCAN_ANON,
	SCAN_FILE,
};

Патч от Google делает так:

<...>
/*
 * Check low watermark used to prevent fscache thrashing during low memory.
 */
static int file_is_low(struct lruvec *lruvec, struct scan_control sc)
{
	unsigned long pages_min, active, inactive;
	enum lru_list inactive_lru = LRU_FILE;
	enum lru_list active_lru = LRU_FILE + LRU_ACTIVE;

	if (!mem_cgroup_disabled())
		return false;

	pages_min = min_filelist_kbytes >> (PAGE_SHIFT - 10);
	inactive = lruvec_lru_size(lruvec, inactive_lru, sc-reclaim_idx);
	active = lruvec_lru_size(lruvec, active_lru, sc->reclaim_idx);

	return ((active + inactive) < pages_min);
}
<...>
/* do not scan file pages when file page count is low */
if (file_is_low(lruvec, sc)) {
	scan_balance = SCAN_ANON;
	goto out;
}

В самом ядре mm/vmscan.c есть такое:

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

При goto out пропускаются переопределения scan_balance и «Calculate the pressure balance between anon and file pages»

При scan_balance == SCAN_ANON ставится scan = 0 (т.е., похоже, принимается решение не «сканировать»), только если сканировалась не файловая страница, т.е. страница не в свопе (??) (терминология от балды, поправьте), в остальных случаях ничего не делается.

lru, который ставится в 0 патчем le9, - это «Pageout list».

В функции shrink_lruvec() в mm/vmscan.c установленная патчем le9 nr[lru] = 0 приводит к тому, что не выполняется reclaim страниц памяти. «Memory reclaim is the mechanism of creating more free RAM pages, by throwing somewhere else the data residing in them.»

Т.е. благодаря патчу le9 не выполняется перекладывание содержимого страниц памяти, если свободной памяти осталось мало (логика зависит от варианта патча).

nr[lru] = scan / 8;

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

В документации к ядру https://www.kernel.org/doc/html/latest/admin-guide/mm/concepts.html написано, что понимается под file и anon:

Whenever a file is read, the data is put into the page cache to avoid expensive disk access on the subsequent reads.

The anonymous memory or anonymous mappings represent memory that is not backed by a filesystem. <…> The page will be marked dirty and if the kernel decides to repurpose it, the dirty page will be swapped out.

in-memory caches of filesystem metadata can be re-read from the storage device and therefore it is possible to discard them from the main memory when system is under memory pressure.

As the load increases, the amount of the free pages goes down and when it reaches a certain threshold (high watermark), an allocation request will awaken the kswapd daemon. It will asynchronously scan memory pages and either just free them if the data they contain is available elsewhere, or evict to the backing storage device (remember those dirty pages?)

Получается, что le9 не дает сделать «just free» - выкинуть ставшее совсем ненужным??

Кажется, понял. В https://paste.rs/aNR.diff «nr[lru] = 0;» делается при if (lru == LRU_ACTIVE_FILE) в цикле прохода всех «страниц», где lru - «страница», для нее ставится 0, грубо говоря. Типа подлежит евикчиванию. И для каждой «страницы» производятся сравнения чисел. По-моему, нет смысла их производить каждый раз.

А ядро-то тухлое, вон, регрессию нашли в бтрфс. Бракоделы! Уже два багфикс-релиза, а сколько еще будет.

должна быть в явном виде ошибка отказа выделения памяти

Виртуальная память-то не ограничена, с чего бы ошибка была? У меня и вовсе оверкоммит не ограничен в опытах.

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

Попытался оптимизировать https://paste.rs/GgX.diff Вынес принятие решения о необходимости предотвращать выселение active file страниц памяти за цикл, получилось так: https://abf.io/mikhailnov/kernel-5.10/blob/bcdf18427e/rosa-le9.diff#lc-146 На момент написания комментария в работе не проверял, не уверен, что оптимизация уместная, т.е. не уверен что цикл идет не слишком долго, грубо говоря.