Skip to content

Conversation

@aenertia
Copy link
Contributor

This commit enables Multi-Gen LRU (CONFIG_LRU_GEN) across supported target kernels. MGLRU replaces the kernel's traditional page reclamation logic with a more efficient multi-generational approach.

This is highly beneficial for memory-constrained ARM SoCs, as it provides better heuristics for identifying "hot" vs "cold" pages, significantly reducing unnecessary I/O and micro-stutters under memory pressure.

Technical Implementation:

Enables CONFIG_LRU_GEN and CONFIG_LRU_GEN_ENABLED.

Targeted at devices running Kernel 6.1 or newer.

Specifically excluded is SDM845 kernels (5.18 kernel).

Initialization and First-Boot Behavior:

Note: Users may observe transient "task wait" messages or increased CPU overhead during the initial boot of a fresh installation. This is a byproduct of MGLRU's generation-tracking heuristics during high-churn operations (such as filesystem expansion and initial cache generation). The scheduler overhead for generation updates stabilizes once the primary working set is established and the initial I/O burst subsides.

This commit enables Multi-Gen LRU (CONFIG_LRU_GEN) across supported target kernels. MGLRU replaces the kernel's traditional page reclamation logic with a more efficient multi-generational approach.

This is highly beneficial for memory-constrained ARM SoCs, as it provides better heuristics for identifying "hot" vs "cold" pages, significantly reducing unnecessary I/O and micro-stutters under memory pressure.

Technical Implementation:

Enables CONFIG_LRU_GEN and CONFIG_LRU_GEN_ENABLED.

Targeted at devices running Kernel 6.1 or newer.

Specifically excluded is SDM845 kernels (5.18 kernel).

Initialization and First-Boot Behavior:

Note: Users may observe transient "task wait" messages or increased CPU overhead during the initial boot of a fresh installation. This is a byproduct of MGLRU's generation-tracking heuristics during high-churn operations (such as filesystem expansion and initial cache generation). The scheduler overhead for generation updates stabilizes once the primary working set is established and the initial I/O burst subsides.
@loki666
Copy link
Contributor

loki666 commented Jan 28, 2026

my undestanding of CONFIG_LRU_GEN is that it's efficient in case of memory pressure workload...
I don't think we can call emulation really a memory pressure workload (vs what a server usually do)
remember we are not building a general purpose kernel

do you have some use case where this KConfig really bring performance improvement in emulation ?

@aenertia
Copy link
Contributor Author

aenertia commented Jan 28, 2026

It works particularly well with zram memory pressure situations yes ; but in general it's more efficient than the old old one as it elimates thrashing the legacy implementation can suffer from. It's lockless basically there is almost down side and potentially may reduce micro stutters as it's generally more efficient and optimized. Especially if kswap is active. But also just generally for how it decides what is page eligible vs the legacy implementation.

So tl;dr potential lower CPU, potential for reducing stutter, battery savings (no locks) and miles better for kswap induced load

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants