[U][M][PATCH 0/1] enable multi-gen LRU by default
Andrea Righi
andrea.righi at canonical.com
Tue Jun 13 08:11:13 UTC 2023
BugLink: https://bugs.launchpad.net/bugs/2023629
[Impact]
Kernels >= 6.1 have the option to use an alternative least-recently-used
(LRU) page reclaiming mechanism, called multi-gen LRU (MGLRU) [1].
In short: the kernel used to maintain two LRU lists of "touched" pages:
the "active" and "inactive" list. The former contains pages thought to
be likely used in the future (working set), while the latter contains
pages thought to be less likely used and therefore likely to be
reclaimed when needed. Pages accessed more frequently are moved to the
active list, while pages accessed less frequently are moved to the
inactive list.
The MGLRU generalizes this concept into multiple generations, instead of
just using two lists. Pages move from older to newer generations when
they are accessed and pages from older generations are reclaimed first
when memory is needed. Generations age over time with new generations
being created as the oldest ones are fully reclaimed.
Fedora [2] and Archlinux [3] both have MGLRU enabled by default and
there are plans to enable this also in Debian and openSUSE.
We should also consider to enable this option across the board for
Mantic, considering that in the future MGLRU is likely to become the
default page reclaiming policy in the kernel.
[1] https://lwn.net/Articles/856931/
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2168435
[3] https://archlinux.org/packages/core/x86_64/linux-lts/
[Test case]
Apache, MariaDB, memcached, MongoDB, PostreSQL, Redis benchmarks can all
show a performance improvement in terms of operations per sec switching
to MGLRU.
[Fix]
Set CONFIG_LRU_GEN_ENABLED=y in config/annotations.
[Regression potential]
This change is going to affect the page reclaiming policy in the kernel,
so a lot of workloads can be potentially affected by this change. We may
experience *performance regressions* especially in those systems that
are running memory intensive workloads or doing large amount of I/O
(page cache being stressed and lots of page reclaiming events are
happening in the system).
However, considering the benefits of this change, especially in the
cloud/server-oriented scenario, and also considering that this option is
likely to become the "default" page reclaiming mechanism in the kernel,
it makes sense to start using it now so that we can catch potential
regressions in advance and act accordingly.
Moreover, this option can still be adjusted at run-time via
/sys/kernel/mm/lru_gen/enabled, so it's very easy to mitigate any
potential regression and rollback to the old behavior if needed.
More information about the kernel-team
mailing list