Убунтята, не проходите мимо: le9 patch добавлен в linux-xanmod и ваш OOM killer будет вылечен

Никаким. Зависит от нагрузки и скорости сторожа.

Защита должна быть для чего-то конкретного: ссх, иксы итп, а поэтому должна задаваться для каждого случая индивидуально и в байтах.

Но у меня нет CONFIG_CGROUP, например. Не хочу возиться с группами. Чем плох такой пример? Общенодовый ключ просто работает. Он гораздо проще в настроке.

А никто о сигруппах сейчас тут и не говорит.

Встречайте: le9ga - следующая стабильная версия le9. https://github.com/hakavlad/le9-patch/blob/main/le9ga_patches/le9ga-5.15.patch

Вижу le9 в pf. MGLRU все равно по умолчанию включен, верно?

Я выбросил mgLRU.

le9ha - это le9ga на стероидах, с явным вызовом oom() при угрозе ООМ. Срабатывает более быстро.

https://github.com/hakavlad/le9-patch/blob/main/le9ha_patches/le9ha-5.15.patch

Позволяет предотвращать fatal io error с i915.

Это предпочтительный вариант для меня.

Отличие от le9ga найдешь в нижней части диффа.

Не забывай обновлять ридми.

Релиза ещё не было.

Отзывы завезли https://github.com/hakavlad/le9-patch/blob/main/USER_FEEDBACK.md

А каков твой опыт с le9?

Строго говоря, я -le9 не пользовался, у меня всегда была своя реализация, основанная на том, что я видел у тебя и у твоих источников.

Новости такие: нет ни одного le9-специфичного бага. Все баги воспроизводятся и без le9.

Например, сегфолты и упсы: https://pastebin.com/kEspr3RG

[ 2664.041054] lxterminal[6167]: segfault at 0 ip 0000000000000000 sp 00007ffc2777d358 error 14 in lxterminal[562afa200000+12000]
[ 2664.041081] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[ 2664.041098] potentially unexpected fatal signal 11.

[ 2671.709249] BUG: unable to handle page fault for address: ffffe2b7f4000008
[ 2671.709258] #PF: supervisor read access in kernel mode
[ 2671.709262] #PF: error_code(0x0000) - not-present page
[ 2671.709264] PGD 0 P4D 0 
[ 2671.709268] Oops: 0000 [#1] SMP PTI
[ 2671.709272] CPU: 7 PID: 6405 Comm: supertuxkart Not tainted 5.15.0.MGLRU #1
[ 2671.709277] Hardware name: Acer VAG70_HC/VAG70, BIOS V2.16 01/14/2013
[ 2671.709279] RIP: 0010:kfree+0x61/0x170
[ 2671.709285] Code: 80 48 01 e8 0f 82 19 01 00 00 48 c7 c2 00 00 00 80 48 2b 15 51 42 ea 00 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 2f 42 ea 00 <48> 8b 50 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 48 8b 48 08 48 8d 51
[ 2671.709288] RSP: 0018:ffffac34824e7a68 EFLAGS: 00010086
[ 2671.709291] RAX: ffffe2b7f4000000 RBX: 0000000000000206 RCX: 0000000000000000
[ 2671.709294] RDX: 000074dc40000000 RSI: ffffffffc1360e25 RDI: 0000000040000000
[ 2671.709296] RBP: 0000000040000000 R08: ffffffffc1456500 R09: 0000000000000000
[ 2671.709298] R10: 0000000000000042 R11: ffffffffc1456120 R12: ffffac34824e7b80
[ 2671.709301] R13: 0000000000000b60 R14: ffff8b238ef1fa80 R15: 0000000000000276
[ 2671.709303] FS:  00007f46c8206800(0000) GS:ffff8b23d3dc0000(0000) knlGS:0000000000000000
[ 2671.709306] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2671.709309] CR2: ffffe2b7f4000008 CR3: 000000005b4f0001 CR4: 00000000001706e0
[ 2671.709311] Call Trace:
[ 2671.709318]  eb_relocate_parse_slow+0x215/0x660 [i915]
[ 2671.709403]  i915_gem_do_execbuffer+0x14c5/0x1ff0 [i915]
[ 2671.709470]  ? wake_all_kswapds+0x67/0xc0
[ 2671.709476]  ? zram_bvec_rw.isra.30+0x46/0x480 [zram]
[ 2671.709480]  ? __cond_resched+0x16/0x40
[ 2671.709483]  i915_gem_execbuffer2_ioctl+0x123/0x270 [i915]
[ 2671.709539]  ? i915_gem_do_execbuffer+0x1ff0/0x1ff0 [i915]
[ 2671.709591]  drm_ioctl_kernel+0xae/0xf0 [drm]
[ 2671.709627]  drm_ioctl+0x234/0x400 [drm]
[ 2671.709651]  ? i915_gem_do_execbuffer+0x1ff0/0x1ff0 [i915]
[ 2671.709702]  ? handle_mm_fault+0x104/0x320

Ядро 5.15.0-mglru с выключенным mglru. Oops происходит при балансировании на низком уровне анонимки. Защита: vm.anon_min_ratio=20.

Все баги воспроизводятся и без le9.

Я тебе, по-моему, говорил точно это же ещё в самом начале.

Хороший патч? Кто-нибудь пользуется?

Я своею разновидностью пользуюсь, норм. Кажется, hakavlad собирает фидбек тут.

	if (!cgroup_reclaim(sc)) {
		unsigned long total_high_wmark = 0;
		unsigned long free, anon;
#if defined(CONFIG_UNEVICTABLE_FILE)
		unsigned long reclaimable_file, clean_file, dirty_file;
#endif
#if defined(CONFIG_UNEVICTABLE_ANON)
		unsigned long reclaimable_anon;
#endif

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

Выключил я как-то защиту набора при cgroup_reclaim, установил vm.anon_min_ratio=100. И вместо запрета своппинга при работе демона memavaild получил прекрасно идущий своппинг.

As mentioned above I am against global knobs to special case the global memory reclaim because that leads to inconsistencies with the memcg reclaim

– https://lore.kernel.org/lkml/Ya3fG2rp+860Yb+t@dhcp22.suse.cz/

Ну и в чем он не прав?

сигруппные лрувекторы могут быть короче глобальных. В le9ec все они находятся под одинаковой защитой. То есть в небольших группах возможен резкий дисбаланс anon/file. В твоем же случае при сигруппном восстановлении защиты вообще не работают. Думаю это наиболее интересный аргумент против le9.

Что же делать, куда бежать.

Что же делать

Искать возможности дальше, привлечь сигруп людей для консультаций, очевидно же. Рассмотреть возможность реализации memory.file.min в сигруппах.

в небольших группах возможен резкий дисбаланс anon/file

Почему нас должно это волновать? Если админ постановил, что нода должна быть под защитой - значит на то есть причины. При нехвтке памяти дисбаланс anon/file - обычное дело. Почему группы должны быть исключением здесь?

Вариант демо: Playing supertux while 1000 tail /dev/zero running simultaneously

https://www.youtube.com/watch?v=ZrLqUWRodh4

Давай теперь то же самое в cyberpunk 2077.

Было б железо под нее, была бы игра в наличии - запросто. Хотя можно попробовать с supertuxkart - она таки пожирнее, чем supertux.

Были такие варианты:

[patch 0/5] refault distance-based file cache sizing https://lore.kernel.org/lkml/1335861713-4573-1-git-send-email-hannes@cmpxchg.org/

[patch 0/8] mm: thrash detection-based file cache sizing v5 https://lore.kernel.org/lkml/1381441622-26215-1-git-send-email-hannes@cmpxchg.org/

[PATCH RFC] mm: lru milestones, timestamps and ages https://lore.kernel.org/all/20130430110214.22179.26139.stgit@zurg/

le9 почти всё: zen и pf отказались от него начиная с 5.16.

Экспансия MGLRU потенциально сделает реализацию le9 невозможной (если удалят старый механизм LRU).

Напоминаю, что min_ttl_ms в MGLRU не позволяет селективно защищать кэш файлов (но это не точно).