Тестируем Linux 5.12—5.17 с патчем Multigenerational LRU Framework

Ранее мы рассмотрели и усовершенствовали работу патча le9 Защищаем чистый кэш файлов при нехватке памяти для предотвращения пробуксовки и livelock

shrink_lru_gens()? Ну или если глубже, то get_nr_to_scan().

или здесь?

static bool should_skip_page(struct page *page, struct scan_control *sc)
{
	if (!sc->may_unmap && page_mapped(page))
		return true;

	if (!(sc->may_writepage && (sc->gfp_mask & __GFP_IO)) &&
	    (PageDirty(page) || (PageAnon(page) && !PageSwapCache(page))))
		return true;

	if (!get_page_unless_zero(page))
		return true;

	if (!TestClearPageLRU(page)) {
		put_page(page);
		return true;
	}

	return false;
}

Вряд ли. Здесь слишком малая гранулярность.

что насчет fill_lru_gen_lists или drain_lru_gen_lists()?

	for_each_evictable_lru(lru) {
		int file = is_file_lru(lru);
		bool active = is_active_lru(lru);
		struct list_head *head = &lruvec->lists[lru];

		if (!lruvec->evictable.enabled[file])
			continue;

выглядит знакомо

Не думаю.

Куда ни глянь - везде работа с отдельными страницами. Нет?

Судя по новости этот патч не про oom, а про активный свопинг. А то что они поломали кучу других механизмов, ну что ж, это гугл! Хотя были у меня какие то надежды что они ускорят процесс.

Судя по новости этот патч не про oom, а про активный свопинг.

Все верно. Однако факт остается фактом - со свопом киллер приходит еще реже, даже когда пора приходить.

они поломали кучу других механизмов

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

они ускорят процесс

Какой процесс?

даже когда пора приходить.

Я всё таки продолжаю считать, что суть подсистемы свопинга в том, чтобы oom вообще никогда не приходил. Это в конце концов последнее средство когда пациенту уже не помочь.

Какой процесс?

Свопинг в ядре однопоточный и очень прожорливый на цпу. Буквально, скорость обработки данных где то между компрессией zip и lzma, причём ближе скорее к lzma. Всякие там zram вполне возможно что упираются совсем не в сжатие-распаковку данных.

https://lore.kernel.org/lkml/20210520065355.2736558-1-yuzhao@google.com/

Новая версия.

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

Нет.

Куда ни глянь, всюду г*вно.

Кстати, вот ещё:

https://github.com/oracle/memoptimizer/

Но уж точно не для того, чтобы убивать задачи пользователя для сохранения комфортного объёма дисковых кешей. А в 95% случаев именно об этом и идёт речь когда говорят о задержке прихода oom. А если своп всё таки имеется и не запрещён, то oom вообще приходит только удастся исчерпать выделенное место на диске.

What's new in v3
================
1) Fixed a bug reported by the Arch Linux kernel team:
   https://github.com/zen-kernel/zen-kernel/issues/207
2) Rebased to v5.13-rc2.

Так себе обновление.

Ведь они не вылечили проблемы, обозначенные в оп-посте. Кстати, куда репортить - в новое обсуждение или в старый v2 тред, если тестировал именно с v2?

не про oom, а про активный свопинг

И про неактивный тоже.

Всякие там zram вполне возможно что упираются совсем не в сжатие-распаковку данных.

zram упирается в распаковку: ЦП загружен на 100% при активном своппинге. Скорость сжатия (и своппинга при этом) зависит от алгоритма zram.

the program initiates compaction with a view to recovering the fragmented memory

Может быть уже не актуально: в 5.8 или 5.9 завезли proactive compaction.

Задача №1 - сброс неактивной анонимной памяти, когда ООМ и рядом не валялся. - Чтобы освободить память для файловых кэшей. Своп может улучшать производительность нагруженного сервера. который нормально работает, и памяти достаточно.

классическая статья: https://chrisdown.name/2018/01/02/in-defence-of-swap.html

Задача№2 - таки да, предотвращение ООМ.

Задача №3 - suspend to disk.

ах, еще #4 существует мнение, что своп используется при дефрагментации памяти - фрагментированные куски перемещаются сначала в своп, и никак иначе. Косвенно подтверждается тем, что при запуске compaction десяток МБ улетает в своп.

swapoff раздела ssd тоже упирается в цпу и идёт примерно с той же скоростью, что и «распаковка» zram. И более того, я ещё никогда не видел чтобы сброс данных на диск при свопинге шёл значительно быстрее этой скорости.

Задачей №1 в последние 30 лет всё таки было расширение физически доступной памяти за счёт диска чтобы вообще в принципе выполнить задачи, превышающие доступный объём памяти. Возможно это не сильно актуально для современных серверов и энтерпрайз спешно пытается переорентировать подсистему на друге здадачи, но…

А по пункту 4 это вообще ходячий анекдот. Серьёзно, дефрагментация памяти, нажми кнопку для ускорения ПК бесплатно и без смс? Был вроде какой то косяк, когда процесс не может освободить страницу памяти если хотя бы один бит ещё используется, но насколько я знаю эта проблема вообще не рассматривается на уровне страниц и подсистема свопинга в принципе не задаётся этим вопросом. А если бы её хотели решить на этом уровне, то надо быть идиотом чтобы в обязательном порядке гонять страницы на диск и обратно чтобы убрать разрежение.

Серьёзно, дефрагментация памяти, нажми кнопку для ускорения ПК бесплатно и без смс?

Теперь кнопка не нужна

compaction_proactiveness

This tunable takes a value in the range [0, 100] with a default value of 20. This tunable determines how aggressively compaction is done in the background. Setting it to 0 disables proactive compaction.

Note that compaction has a non-trivial system-wide impact as pages belonging to different processes are moved around, which could also lead to latency spikes in unsuspecting applications. The kernel employs various heuristics to avoid wasting CPU cycles if it detects that proactive compaction is not being effective.

Be careful when setting it to extreme values like 100, as that may cause excessive background compaction activity.

https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/sysctl/vm.rst#compaction_proactiveness

см также https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/

Тестируешь новую серию и репортишь в новую ветку.

Одно другому не мешает.

The multigenerational lru should perform optimally out of the box

как вам такое?

https://forum.xanmod.org/thread-4102-post-7597.html#pid7597

Join #pfkernel @ Libera.Chat IRC.

Ты зачем из фриноды ушел? Нормально же общались.

Тебе припекает?

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

АПВС?

АПВОВНВ?

Не засоряй эфир.

Как это вяжется с повсеместной рандомизацией памяти как защиты от многих атак? И разумеется с тем, что доступ к рандомизированной и фрагментированной ОЗУ имеет ту же скорость, что и к дефрагментированной. Это для начала, не читая статей.

Накатил 5.13.0-rc2-mg-LRU.

Проблемы с приходом киллера со свопом не воспроизводятся, однако защита файловых страниц по-прежнему не работает как следует (swappiness=200 не защищает файловый кэш, или защищает слабо).

Подробности позже.

Удалось воспроизвести значительную задержку киллера с запущенным браузером и ютубом во вкладке (киллер приходил нормально без запущенных приложений).

Логи

mem2log https://pastebin.com/3bCUWFci

psi2log https://pastebin.com/bC00jWUz

Давление памяти под сотню пока ждем киллера. post-factum

Еще пример: вкладка с ютубом + tail /dev/zero. Ждал киллера больше минуты при зависшей системе.

mem2log https://pastebin.com/GCFVkTr5

psi2log https://pastebin.com/QGjtxsW7

Система на HDD, своп на zram.

тот же опыт, логи с таймстемпами

mem2log https://pastebin.com/raw/9s0PuUrA

psi2log -m0 https://pastebin.com/raw/7ui5xatN

psi2log -m2 https://pastebin.com/raw/LAYLa5dz (здесь psi2log завис на 70 секунд несмотря на mlockall)

Надо софт оптимизировать, чтобы память не жрал, а не oom-киллеры писать.

Как сломан vm.watermark_scale_factor.

С классическим LRU, если swappiness=0 или имеет прочие низкие значения, повышение vm.watermark_scale_factor приводит к повышению уровня файл кэша, и своппинг продвигается легко, и система не виснет.

Что имеем с мультиген:

если swappiness=0 и vm.watermark_scale_factor=100, то своппинг не продвигается совсем, киллер не приходит, давление памяти под сотню, система мертва (при отключениии мультиген своппинг идет легко при сохранении файлового кэша).

логи

mem2log https://pastebin.com/0Ft1KkPG - файл падает в ноль, своп при этом не задействуется.

psi2log https://pastebin.com/raw/rxfRLp10 - давление при этом под сотню, киллера дождаться надежды не было, вызывал киллера руками.

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

А прочитав статью я так и не понял, а собственно нахрена? Память процессов виртуальна и рандомизирована, драйвера и всякие железо-специфичные буферы погоду делают редко или крайне редко. Разделяемая память? Ну допустим, я хз как это работает, но её же в норме немного.

Классика. Уже пожертвуйте индусов из microsoft/reactos/haiku/kolibrios, чтобы исправили VM в ядре, уже ясно что кто угодно в этом соображает лучше разработчиков ядра.

Это бессмысленно. Когда достаточно большое количество данных будет гоняться из/в свап, 99.(9)% времени работы компа будет занято сваппингом. Это замедлит работу компа до абсолютно бессмысленно медленной. Свапить имеет смысл пока средний отклик ещё остаётся более-менее терпимым. Дальше нужно валится, тк продолжать бессмысленно становится.

Ты там опыт со своим говноплатником не проецируй на нормальных людей.

Никто в здавом уме не гоняет задачи в свопе.

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

Нужно и то и другое одновременно, а ложные дихотомии не нужны.

mgLRU различает только swappiness=0 и swappiness>0.

При нулевом происходит полный запрет своппинга.

При положительном ведет себя примерно как с классическим LRU при swappiness=100 и watermark_scale_factor=1.

swappiness=200 с mgLRU не работает, в io-bound задачах поэтому mgLRU может проигрывать.

Надеюсь зарепортить это позже в LKML.

Что-то пока тихо совсем в треде v3.

post-factum Таким образом, все тезисы справедливы и для v3.

Ага, когда когда при компиляции Хромиума g++ забивает мне память и своп под завязку, оптимизировать его жор конечно же не нужно, пусть лучше ядро его прибивает. А вот clang справляется в этом плане куда лучше - сразу видно, что люди делали.