LINUX.ORG.RU

Linux 5.10

 ,


1

3

Тихо и незаметно состоялся релиз ядра версии 5.10. По признанию самого Торвальдса, ядро «состоит из по большей части новых драйверов с вкраплениями из патчей», что неудивительно, ибо ядро получило статус LTS.

Из нового:

  • Поддержка fast_commit в файловой системе Ext4. Теперь приложения будут писать в кэш меньше метаданных, что ускорит запись! Правда, её надо явно включить при создании ФС.

  • Дополнительные настройки доступа через интерфейс io_uring, которые позволяют безопасно давать доступ к ресурсам колец дочерним приложениям.

  • Введён системный вызов process_madvise, позволяющий давать ядру информацию об ожидаемом поведении целевого приложения. Аналогичная система, кстати, используется в Android (демон ActivityManagerService).

  • Исправлена проблема 2038 года для файловой системы XFS.

и многое другое.

Также стоит отметить, что тут же была выпущена версия 5.10.1, отменяющая два изменения, приводившие к проблемам в подсистемах md и dm raid. Так что да, 0-day-патчи бывают даже для ядра Linux.

Подробнее:

>>> Скачать tarball

★★★★

Проверено: Zhbert ()

Ответ на: комментарий от hakavlad

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

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

mikhailnov ()
Ответ на: комментарий от mikhailnov

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

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

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

hakavlad ★★ ()

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

anonymous ()
Ответ на: комментарий от mikhailnov

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

post-factum ★★★★★ ()
Ответ на: комментарий от hakavlad

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

post-factum ★★★★★ ()
Ответ на: комментарий от hakavlad

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

post-factum ★★★★★ ()
Ответ на: комментарий от hakavlad

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

hakavlad ★★ ()
Ответ на: комментарий от hakavlad

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

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

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

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

дек 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 и открытие вкладок). Не зависло, но упала сессия.

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от hakavlad

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

hakavlad ★★ ()
Ответ на: комментарий от post-factum

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

+#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

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

anonymous ()
Ответ на: комментарий от post-factum
#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

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

anonymous ()
Ответ на: комментарий от post-factum

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

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

			scan = lruvec_size - lruvec_size * protection /
				cgroup_size;
anonymous ()
Ответ на: комментарий от post-factum

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

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.

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 2)
Ответ на: комментарий от post-factum

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

#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 - здесь чем болше фактор, тем жестче защита.

hakavlad ★★ ()
Ответ на: комментарий от hakavlad

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

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

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от post-factum

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

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от hakavlad

Не, мне вообще не нравятся дополнительные ручки. Я тут подумал, и я бы 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. Можно сделать не линейно, а экспоненциально.

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

Как говорилось выше, бывали проблемы с жесткой защитой - падения сессии в некоторых кейсах. Поэтому хочу оставить мягкую защиту и как минимум 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
anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от hakavlad

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

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

mikhailnov ()
Ответ на: комментарий от mikhailnov

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

В ядре есть:

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 не выполняется перекладывание содержимого страниц памяти, если свободной памяти осталось мало (логика зависит от варианта патча).

mikhailnov ()
Ответ на: комментарий от mikhailnov

В документации к ядру 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» - выкинуть ставшее совсем ненужным??

mikhailnov ()
Ответ на: комментарий от mikhailnov

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

mikhailnov ()

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

anonymous ()
Ответ на: комментарий от mikhailnov

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

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

hakavlad ★★ ()
Ответ на: комментарий от post-factum

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

mikhailnov ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.