ACK: [U][M][PATCH 0/1] enable multi-gen LRU by default

[Tim Gardner]

On 6/13/23 01:11, Andrea Righi wrote:
> 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.
> 
> 
Acked-by: Tim Gardner <tim.gardner at canonical.com>
-- 
-----------
Tim Gardner
Canonical, Inc