LINUX.ORG.RU

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

 ,


1

2

Новость о патче: https://www.opennet.ru/opennews/art.shtml?num=54972

Пришло время тестировать ядро с этим патчем. Патч принят в linux-zen, и соответственно буду тестировать zen-kernel-5.12.4-zen1.

TLDR;

  • OOMK Killer приходит даже с еще большей задержой, чем при отключении multigen LRU;
  • работа vm.swappiness сломана;
  • работа vm.watermark_scale_factor сломана;
  • при включении multigen LRU не работают эффекты патча le9 [1], обеспечивающего защиту чистого кэша файлов.

Подробности далее.

[1] https://github.com/hakavlad/le9-patch

Призывается @post-factum

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

или здесь?

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;
}
hakavlad ★★ ()
Ответ на: комментарий от kirill_rrr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/

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

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

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

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

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

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

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

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

Логи

mem2log https://pastebin.com/3bCUWFci

psi2log https://pastebin.com/bC00jWUz

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

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

Как сломан 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 - давление при этом под сотню, киллера дождаться надежды не было, вызывал киллера руками.

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

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

kirill_rrr ★★★★★ ()

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

LongLiveUbuntu ★★★★★ ()