** Description changed: [Impact] Kernels >= 6.1 have the option to use an alternative least-recently-used (LRU) page reclaiming mechanism, called multi-gen LRU [1]. In short: the kernel used to maintain two LRU lists of "touched" pages: the "active" and "inactive" lists. 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 multi-generational LRU (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, Google is going to - enable this option in their Container-Optimized OS [4] and there are - plans to enable this option also in Debian and openSUSE. + Fedora [2] and Archlinux [3] both have MGLRU enabled and there are plans + to enable this option also in Debian and openSUSE. We should also consider to enable this option across the board for Mantic, considering that in the future the multi-gen LRU is likely to become the default page reclaiming mechanism 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/ - [4] https://cloud.google.com/container-optimized-os/docs [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 kernel config/annotations. [Regression potential] This change is going to affect the page reclaiming mechanism 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 enabling this option now so that we can catch potential regressions in advance and act accordingly.
** Description changed: [Impact] Kernels >= 6.1 have the option to use an alternative least-recently-used (LRU) page reclaiming mechanism, called multi-gen LRU [1]. In short: the kernel used to maintain two LRU lists of "touched" pages: the "active" and "inactive" lists. 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 + 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 multi-generational LRU (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 and there are plans to enable this option also in Debian and openSUSE. We should also consider to enable this option across the board for Mantic, considering that in the future the multi-gen LRU is likely to become the default page reclaiming mechanism 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 kernel config/annotations. [Regression potential] This change is going to affect the page reclaiming mechanism 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 enabling this option now so that we can catch potential regressions in advance and act accordingly. ** Description changed: [Impact] Kernels >= 6.1 have the option to use an alternative least-recently-used (LRU) page reclaiming mechanism, called multi-gen LRU [1]. In short: the kernel used to maintain two LRU lists of "touched" pages: the "active" and "inactive" lists. 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 multi-generational LRU (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 and there are plans to enable this option also in Debian and openSUSE. We should also consider to enable this option across the board for Mantic, considering that in the future the multi-gen LRU is likely to - become the default page reclaiming mechanism in the kernel. + 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 kernel config/annotations. [Regression potential] This change is going to affect the page reclaiming mechanism 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 enabling this option now so that we can catch potential regressions in advance and act accordingly. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2023629 Title: enable multi-gen LRU by default Status in linux package in Ubuntu: Incomplete Status in linux source package in Mantic: Incomplete Bug description: [Impact] Kernels >= 6.1 have the option to use an alternative least-recently- used (LRU) page reclaiming mechanism, called multi-gen LRU [1]. In short: the kernel used to maintain two LRU lists of "touched" pages: the "active" and "inactive" lists. 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 multi-generational LRU (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 and there are plans to enable this option also in Debian and openSUSE. We should also consider to enable this option across the board for Mantic, considering that in the future the multi-gen LRU 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 kernel config/annotations. [Regression potential] This change is going to affect the page reclaiming mechanism 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 enabling this option 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2023629/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
