LINUX.ORG.RU

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

 ,


1

3

Новость о патче: 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

★★★

Последнее исправление: hakavlad (всего исправлений: 5)

Ответ на: комментарий от post-factum
$ uname -r
5.16.0-rc1.le9ec

Первые опыты: без le9 заметил замедление прихода киллера после tail /dev/zero (по сравнению с более старыми ядрами), по крайней мере без свопа. Более длительные зависания около ООМ. Логи двух запусков tail /dev/zero без свопа:

mem2log: https://pastebin.com/hhUrNyvm

psi2log: https://pastebin.com/WxmuBeaX

Тут по 20 сек зависания вместо 2 сек.

Продолжение следует.

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

vm.clean_min_kbytes=333000

  0.6 |   0.0   0.0 |   0.0   0.0 | 2.002
  0.8 |   0.5   0.4 |   0.0   0.0 | 2.002
  1.1 |   0.2   0.1 |  29.7  27.8 | 2.002
  0.6 |   0.0   0.0 |  95.2  93.3 | 2.002
  0.4 |   0.0   0.0 |  92.5  91.3 | 2.002
  0.4 |   0.0   0.0 |  94.6  93.5 | 2.0
  0.3 |   0.0   0.0 |  94.5  93.5 | 2.002
  0.5 |   0.4   0.4 |  92.4  91.3 | 2.002
  0.4 |   0.0   0.0 |  95.6  94.8 | 2.002
  0.4 |   0.0   0.0 |  94.9  94.0 | 2.002
  0.4 |   0.0   0.0 |  96.2  95.3 | 2.002
  0.2 |   0.0   0.0 |  98.0  97.4 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.4 |   1.0   1.0 |  97.1  94.4 | 2.002
  0.1 |   0.0   0.0 |  96.2  95.8 | 2.002
  1.1 |   0.0   0.0 | 102.9  59.9 | 2.002
  1.3 |   0.6   0.5 |   2.3   2.0 | 2.002
  1.4 |   0.2   0.2 |   0.0   0.0 | 2.002

Задержка киллера вместо мгновенного ООМ.

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

Это нужно репортить в linux-mm? Это новая неизвестная регрессия?

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

Под защитой: в течение 20 сек давление памяти под сотню вместо мгновенного ООМ.

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

Во-первых, это красиво:

  0.3 |   0.1   0.1 |  85.7  84.8 | 2.002
  0.2 |   0.0   0.0 |  95.4  94.8 | 2.002
  0.2 |   0.0   0.0 |  97.8  97.2 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.6 | 2.002
  0.2 |   0.0   0.0 |  97.8  97.4 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.001
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.1 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.003
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.3 |   0.0   0.0 | 100.0  99.7 | 2.002
  0.2 |   0.0   0.0 | 100.0  99.7 | 2.002
  7.7 |  10.0   2.0 |  69.6  66.1 | 2.001
  1.3 |  19.8  15.3 |   2.1   1.3 | 2.002
  0.6 |  29.3  23.0 |   4.8   4.5 | 2.002
  0.5 |  22.2  19.0 |   7.4   6.9 | 2.002
  0.7 |  28.9  24.6 |   3.5   3.1 | 2.002
  1.0 |  39.5  35.5 |   0.0   0.0 | 2.002
  0.8 |   7.6   7.1 |   0.1   0.1 | 2.002
  0.7 |   0.2   0.2 |   0.0   0.0 | 2.002
  0.7 |   0.2   0.2 |   0.0   0.0 | 2.002

Чистая соточка - это some memory pressure. 12 гиг памяти, 40 гиг свопа, 333К жестк защита, был запущен tail /dev/zero.

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

Еще пример: 333K защита, 12ГБ памяти, 12ГБ своп. Полторы минуты зависание.

mem2log https://pastebin.com/8nkmKrdf

psi2log https://pastebin.com/5WcQ2jWg

Картина похожа на известный баг, который воспроизводился ранее с MGLRU https://github.com/zen-kernel/zen-kernel/issues/223

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

При использовании le9 на стероидах (экспериментальные линейки с явным вызовом oom() при длительном нулевом возврате) приводят к даблкиллам с 5.16. Со старыми ядрами такой проблемы не было.

Всё сломали в 5.16!

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

ХЗ баг ли это.

Для меня это очевидная регрессия. Надо репортить.

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

Фикс найден. Просто уменьшаем таймауты здесь в vmscan.c

	case VMSCAN_THROTTLE_NOPROGRESS:
		timeout = HZ/2;
		break;
	case VMSCAN_THROTTLE_ISOLATED:
		timeout = HZ/50;
		break;
	default:
		WARN_ON_ONCE(1);
		timeout = HZ;
		break;
	}

Ломающий патч был тут: https://lwn.net/ml/linux-kernel/20211022144651.19914-7-mgorman@techsingularity.net/

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

Потрясающие новости: fatal io error не воспроизводится с 5.16-le9.

И уточнение. Кратчайший фикс:

	case VMSCAN_THROTTLE_NOPROGRESS:
		timeout = HZ/2;

– здесь таймаут ставим в 0, и проблема уходит. По крайней мере при использовании le9. Нужно ли сокращать другие таймауты? Насколько? В чем минус низких значений? Какое значение предложить сообществу?

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

Ну так и задумано же. Горман: дефолты взяты с потолка, возможно стоит подкорректировать. Это тновая эвристика. Первый релиз - и, конечно, плохие дефолты.

hakavlad ★★★
() автор топика
Ответ на: комментарий от post-factum
+	 * These figures are pulled out of thin air.
This patch centralises the timeout values and selects a timeout based
on the reason for reclaim throttling. These figures are also pulled
out of the same thin air but better values may be derived

https://lwn.net/ml/linux-kernel/20211022144651.19914-7-mgorman@techsingularity.net/

Какова эвристика - таков и фикс.

hakavlad ★★★
() автор топика
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от post-factum
void reclaim_throttle(pg_data_t *pgdat, enum vmscan_throttle_state reason)
{
	return;

– выключение тротлинга возвращает поведение как в 515: c le9 вообще нет лагов, но возщвращается fatal io error.

C нулевым таймаутом с le9 есть микрофризы в районе ООМ, а без le9 все еще возможны многосекундные лаги.

Таким образом, для меня кажется оптимальным это: нулевой таймаут. Это исправляет побочку (fatal io err с i915) ценой микрофриза около ООМ.

Вопрос оптимальных дефолтов остается открытым: также брать с потолка или ввести новую ручку (vm.reclaim_throttle_factor или даже несколько ручек).

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

Почему бы не поофигевать в ring0?

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

BTW, обнуление MAX_RECLAIM_RETRIES также резко сокращает период зависания. Обнуление MAX_RECLAIM_RETRIES также является альтернативой выключению reclaim_throttle().

Добавление reclaim_throttle() является неплохим поводом для пересмотра значения MAX_RECLAIM_RETRIES.

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

Замечал, что вычищает старый кеш со временем. Разницу с защитой по lru_gen/min_ttl_ms и без неё не особо заметил, тут уже ты сам тестируй.

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

one test shows an 89% reduction in system CPU time

Странно, что фороникс молчит о столь значительных улучшениях.

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

Пришли тут обнуляторы мой mbr обнулять…

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

Какой min_ttl_ms используешь

https://build.opensuse.org/package/view_file/home:post-factum/pf-vendor/mm_lru_gen_min_ttl_ms.service?expand=1

и почему?

https://github.com/zen-kernel/zen-kernel/commit/f16e06ddde0e38b172d8da03d4fd39c3296b0564

Что не так с le9, кстати?

Оно не идёт в апстрим, в отличие от mgLRU.

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

Как минимум ДЛЯ СЕБЯ - хромос и серверы.

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

это инженерное время

Это ничто для гиганта. Как будто там 10000 инжереров это пилят.

anonymous
()
Ответ на: комментарий от post-factum
  • с жесткой защитой с le9 - лагов нет, как с 515.
  • без защиты лаги есть, иногда не длинные, иногда длинные.
hakavlad ★★★
() автор топика
Ответ на: комментарий от hakavlad

Есть нормальный интерфейс вместо этого lore.kernel.org? А то весь экран мусором засран и хрен поймёшь кто кому отвечает?

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

Еще раз посмотри сюда:

https://lore.kernel.org/lkml/20211128042635.543a2d04@mail.inbox.lv/

Внизу дерево ответов, так что все понятно и ничего не засрано:

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25 15:18 Mel Gorman
2021-11-26 10:14 ` Vlastimil Babka
2021-11-26 10:26 ` Mike Galbraith
2021-11-26 16:12 ` Alexey Avramov
2021-11-26 16:52   ` Mel Gorman
2021-11-27 19:26     ` Alexey Avramov [this message]
hakavlad ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.