LINUX.ORG.RU
Форум — General  

Тестируем 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)

 ← 1 2 3 4 →
Ответ на: комментарий от post-factum

Потестировал mglru предмет экономии энергии с использованием свеженаписанного times2log.

В свопоёмких и энергоёмких задачах, действительно, на 15-30% меньше расход энергии kswapd0 и такое же ускорение выполнения задач.

Тест был: наполнить длинный список и несколько раз перезаписать элементы при глубоком своппинге на zram.

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

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

@post-factum

516 демонстрирует в том же тесте значительный прирост производительности, приближаясь к mglru.

515: 567/526, 575/514

515-mglru: 432/392

516: 450/414, 447/410

Первое - время теста, второе - время CPU kswapd0.

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

Похоже, что фикс от Гормана таки попал в mainline в последний момент, ждем 5.16-rc8 без бага: https://lore.kernel.org/linux-mm/CAHk-=whj9ZWJ2Fmv2vY-NAB_nR-KgpzpRx6Oxs=ayyTEN7E8zw@mail.gmail.com/

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

Линус ворвался в тред и оставил включение патча на усмотрение Эндрю:

I'll leave this to Andrew. I had some stylistic nits, but all the
actual complexity is in that aging and eviction, and while I looked at
the patches, I certainly couldn't make much of a judgement on them.

The proof is in the numbers, and they look fine, but who knows what
happens when others test it. I don't see anything that looks worrisome
per se, I just see the silly small things that made me go "Eww".

             Linus

https://lore.kernel.org/linux-mm/CAHk-=whMbX+GUBY=Fyxo3r-XVvfNyFA+4hUJS7UxgYDxf9Wbcw@mail.gmail.com/

Какое стремительное развитие событий!

anonymous
()

ипать какой dumpster fire эта ваша vm

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

С заведомо менее выигрышным, зато апстримным вариантом)

Впрочем, кто такой автор le9 против инженеров самого Гугла!

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

С заведомо менее выигрышным

Большинство отзывов положительные у мглру, отрицательных отзывов практически не было. Серверы БД выигрывают в перфомансе в бенчах: https://lore.kernel.org/lkml/20220104202227.2903605-1-yuzhao@google.com/

Даже у меня была синтетика, в которой мглру давал результат, недостижимый при использовании старого механизма LRU: Тестируем Linux 5.12—5.17 с патчем Multigenerational LRU Framework (комментарий)

Однако это не отменяет того, что существуют нагрузки, с которыми MGLRU не может достичь результата, достижимого со старым LRU. Это cache bound нагрузки при нехватке памяти, с которыми можно достичь максимальной производительности при swappiness=200 со старым LRU. Но, как известно в узких кругах, обработка swappiness в MGLRU другая и выглядит как совершенно сломанная (с MGLRU изменения swappiness слабо влияют на сохранность кэша при нехватке памяти).

Похоже, что использующийся сейчас механизм LRU в ядре - это уже legacy LRU. Более интересный вопрос сейчас - когда из ядра выкинут старый алгоритм LRU.

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

Может MGLRU еще исправят и улучшат, так что найденные мной кейсы с проигрышем LRU будут столь же производительны, как и со старым LRU. А может ничего не исправят и все будет также плохо, но, несмотря на это, старый LRU все равно выкинут. Время покажет.

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

Большинство отзывов положительные у мглру, отрицательных отзывов практически не было.

Естественно в сравнении со стоком, а не с le9?

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

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.0 MiB in 21.4s (avg 1405.1 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.0 MiB in 21.9s (avg 1371.5 MiB/s)


mglru0 swappinwss100

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.1 MiB in 214.9s (avg 139.6 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.1 MiB in 63.6s (avg 471.9 MiB/s)


mglru0 swappinwss10

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.0 MiB in 1649.7s (avg 18.2 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000

total read 30000.0 MiB in 1106.9s (avg 27.1 MiB/s)

mglru1 swappinwss200

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.0 MiB in 319.8s (avg 93.8 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.0 MiB in 55.9s (avg 536.6 MiB/s)


mglru1 swappinwss100

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.0 MiB in 394.8s (avg 76.0 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.0 MiB in 55.2s (avg 543.4 MiB/s)


mglru1 swappinwss10

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.0 MiB in 294.0s (avg 102.0 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.0 MiB in 55.3s (avg 542.7 MiB/s)


mglru1 swappinwss2

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
total read 30000.0 MiB in 347.5s (avg 86.3 MiB/s)

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.0 MiB in 55.8s (avg 537.5 MiB/s)


mglru1 swappinwss1

cache-bench -f test500 -p 1 -b 1 -m 0 -r 30000
  read 14.1M in 2.0s (7.0M/s); total 20967.2M in 1556.0s, avg 13.5M/s
слишком долго, не закончил.

cache-bench -f test500 -p 1 -b 1 -m 1 -r 30000
total read 30000.0 MiB in 68.3s (avg 439.0 MiB/s)

Это итоги краткого тестирования влияния swappiness на производительность cache bound операций. Итоги всё те же:

  • лучшую производительность обеспечивает старый LRU при swappiness=200, и это результат недостижим с MGLRU
  • в этом тесте при использовании MGLRU результат отличается только при swappiness=1 - приэтом падает производительность cache bound операций. В диапазоне swappiness 2-200 резульатат не мениялся.
  • со старым LRU swappiness сильно влияет на результат, и с понижением swappiness падает эффективность кэширования при нехватке памяти. Старый LRU позволяет максимально гибко настраивать сохранность кэша при нехватке памяти.

Для тестирования использовался https://github.com/hakavlad/cache-bench

Спрашивайте ответы.

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

https://imgur.com/a/ovrjHid

– агрессивный своппинг при swappiness=1 при чтении из большого ммапленного файла. Здесь три момента:

  • понижение swappiness с MGLRU не мешает свопиться агрессивно.
  • кэш, полученный путем чтения из ммапленного файла, получает защиту даже при минимальном swappiness.
  • объем кэша колеблется волнообразно с MGLRU. С классическим LRU под давлением памяти линия доступной памяти идет практически ровно.
hakavlad ★★★
() автор топика
Ответ на: комментарий от post-factum

min_ttl_ms=1000, свободного свопа много, гуй жив,

$ timeout 60 stress -m 40 --vm-bytes 1G
stress: info: [41513] dispatching hogs: 0 cpu, 0 io, 40 vm, 0 hdd
stress: FAIL: [41513] (415) <-- worker 41551 got signal 9
stress: WARN: [41513] (417) now reaping child worker processes
stress: FAIL: [41513] (421) kill error: No such process
stress: FAIL: [41513] (415) <-- worker 41553 got signal 9
stress: WARN: [41513] (417) now reaping child worker processes
stress: FAIL: [41513] (421) kill error: No such process
stress: FAIL: [41524] (522) memory corruption at: 0x7feab4fe8010
stress: FAIL: [41513] (394) <-- worker 41524 returned error 1
stress: WARN: [41513] (396) now reaping child worker processes
stress: FAIL: [41513] (400) kill error: No such process

– при этом ядро с MGLRU поубивало процессы. Это же так и задумано, верно?

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

можно прям отсюда по частям https://lore.kernel.org/lkml/20220208081902.3550911-1-yuzhao@google.com/

внизу список из 12 частей

2022-02-08  8:18 ` [PATCH v7 01/12] mm: x86, arm64: add arch_has_hw_pte_young() Yu Zhao
2022-02-08  8:24   ` Yu Zhao
2022-02-08 10:33   ` Will Deacon
2022-02-08  8:18 ` [PATCH v7 02/12] mm: x86: add CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG Yu Zhao
2022-02-08  8:27   ` Yu Zhao
2022-02-08  8:18 ` [PATCH v7 03/12] mm/vmscan.c: refactor shrink_node() Yu Zhao
2022-02-08  8:18 ` [PATCH v7 04/12] mm: multigenerational LRU: groundwork Yu Zhao
2022-02-08  8:28   ` Yu Zhao
2022-02-08  8:18 ` [PATCH v7 05/12] mm: multigenerational LRU: minimal implementation Yu Zhao
2022-02-08  8:33   ` Yu Zhao
2022-02-08 16:50   ` Johannes Weiner
2022-02-08  8:18 ` [PATCH v7 06/12] mm: multigenerational LRU: exploit locality in rmap Yu Zhao
2022-02-08  8:40   ` Yu Zhao
2022-02-08  8:18 ` [PATCH v7 07/12] mm: multigenerational LRU: support page table walks Yu Zhao
2022-02-08  8:39   ` Yu Zhao
2022-02-08  8:18 ` [PATCH v7 08/12] mm: multigenerational LRU: optimize multiple memcgs Yu Zhao
2022-02-08  8:18 ` [PATCH v7 09/12] mm: multigenerational LRU: runtime switch Yu Zhao
2022-02-08  8:42   ` Yu Zhao
2022-02-08  8:19 ` [PATCH v7 10/12] mm: multigenerational LRU: thrashing prevention Yu Zhao
2022-02-08  8:43   ` Yu Zhao
2022-02-08  8:19 ` [PATCH v7 11/12] mm: multigenerational LRU: debugfs interface Yu Zhao
2022-02-08  8:19 ` [PATCH v7 12/12] mm: multigenerational LRU: documentation Yu Zhao
hakavlad ★★★
() автор топика
Ответ на: комментарий от post-factum

Есть несколько стульев:

+Values Features
+====== ========
+0x0001 the multigenerational LRU
+0x0002 clear the accessed bit in leaf page table entries **in large
+       batches**, when MMU sets it (e.g., on x86)
+0x0004 clear the accessed bit in non-leaf page table entries **as
+       well**, when MMU sets it (e.g., on x86)
+[yYnN] apply to all the features above

https://lore.kernel.org/linux-mm/20220208081902.3550911-13-yuzhao@google.com/

На какой сам сядешь, а на какой мать посадишь?

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

На самом деле там 8 стульев из диапазона [0; 7]. Установка 8 в /sys/kernel/mm/lru_gen/enabled возвращает переключатель в 0.

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

should enable or disable

Как это понимать? Так включать или не включать?

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

Получил ли ты это письмо? https://lore.kernel.org/linux-mm/20220212051219.183d1baf@PC/

Моя почтовая служба забанила меня немедленно после отправки этого письма. В lore/lkml оно не отображается.

Впрочем, тебя и не видно в СС.

hakavlad ★★★
() автор топика
Последнее исправление: hakavlad (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 →
General