[PATCH] mm: Protect clean file pages under memory pressure to prevent thrashing, avoid high latency and prevent livelock in near-OOM conditions

[hakavlad]

Please look at this https://github.com/hakavlad/le9-patch

https://github.com/hakavlad/le9-patch/blob/main/le9db_patches/le9db-5.13-rc2-mg-LRU-v3.patch may be applied to zen 5.12-5.13. I suggest this patch to be applied to linux-zen.

See also

https://www.phoronix.com/scan.php?page=news_item&px=le9-Linux-Low-RAM and comments

https://forum.xanmod.org/thread-4102-post-7562.html

hakavlad/le9-patch#4 and https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/en/

[damentz]

Thanks, this patchset looks safe and straightforward to add. I ended up using the 5.14 release candidate for the 5.13 branch since 5.13's memory subsystem changed quite a bit since rc2.

Also, with both 5.12 and 5.13, I set a default value of effectively 256mb soft and 64mb hard cache protection. Should make it easier for any package maintainers to pick up this change without needing to research too much into it.

[hakavlad]

64mb hard cache protection

Note that hard protection may cause these issues with DRM/i915:

• [DRM/i915] fatal IO error 11 (Resource temporarily unavailable) hakavlad/le9-patch#5
• [DRM/i915] kernel: BUG: unable to handle page fault / kernel: Oops hakavlad/le9-patch#6

https://github.com/hakavlad/le9-patch#warnings

Soft protection should be safe and 256MB is OK.

[damentz]

@hakavlad thanks for the warning, dropped CLEAN_MIN_KBYTES to zero.

[hakavlad]

Also note that le9 doesn't work with mg-LRU [1]. If you are using mg-LRU, than le9 will not work (mg-LRU doesn't use get_scan_count()).

[1] https://forum.xanmod.org/thread-4102-post-7599.html#pid7599

[travankor]

@yuzhaogoogle "Protecting file pages with mgLRU will require a completely different approach than in le9. I do not yet know how to implement protection of file pages when using mgLRU."

Do you plan to implement this for mgLRU?

Yes, sometime next week.

Circling back on this: now echo 1000 >/sys/kernel/mm/lru_gen/min_ttl_ms can protect both anon and file memory that is used within the last 1000ms. Feel free to adjust this value to fit into your use cases. @travankor

[travankor]

I will try this out soon, thanks. What are the trade-offs when tweaking (larger and smaller) this with sysctl?

Oom kill more aggressively (more get killed) but more responsive user experience
or
oom kill less aggressively (fewer get killed) but less responsive user experience.

Does it make sense?