Re: [PATCH v6 0/9] Multigenerational LRU Framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-01-11 09:41, Yu Zhao wrote:
On Tue, Jan 04, 2022 at 01:30:00PM -0700, Yu Zhao wrote:
On Tue, Jan 04, 2022 at 01:22:19PM -0700, Yu Zhao wrote:
TLDR
====
The current page reclaim is too expensive in terms of CPU usage and it
often makes poor choices about what to evict. This patchset offers an
alternative solution that is performant, versatile and
straightforward.

<snipped>

Summery
=======
The facts are:
1. The independent lab results and the real-world applications
    indicate substantial improvements; there are no known regressions.
2. Thrashing prevention, working set estimation and proactive reclaim
    work out of the box; there are no equivalent solutions.
3. There is a lot of new code; nobody has demonstrated smaller changes
    with similar effects.

Our options, accordingly, are:
1. Given the amount of evidence, the reported improvements will likely
    materialize for a wide range of workloads.
2. Gauging the interest from the past discussions [14][15][16], the
    new features will likely be put to use for both personal computers
    and data centers.
3. Based on Google's track record, the new code will likely be well
    maintained in the long term. It'd be more difficult if not
    impossible to achieve similar effects on top of the existing
    design.

Hi Andrew, Linus,

Can you please take a look at this patchset and let me know if it's
5.17 material?

My goal is to get it merged asap so that users can reap the benefits
and I can push the sequels. Please examine the data provided -- I
think the unprecedented coverage and the magnitude of the improvements
warrant a green light.

Downstream kernel maintainers who have been carrying MGLRU for more than
3 versions, can you please provide your Acked-by tags?

Having this patchset in the mainline will make your job easier :)

    Alexandre - the XanMod Kernel maintainer
                https://xanmod.org
Brian - the Chrome OS kernel memory maintainer
                https://www.chromium.org
Jan - the Arch Linux Zen kernel maintainer
                https://archlinux.org
Steven - the Liquorix kernel maintainer
                https://liquorix.net
Suleiman - the ARCVM (Android downstream) kernel memory maintainer
                https://chromium.googlesource.com/chromiumos/third_party/kernel

Also my gratitude to those who have helped test MGLRU:

    Daniel - researcher at Michigan Tech
             benchmarked memcached
Holger - who has been testing/patching/contributing to various
             subsystems since ~2008
Shuang - researcher at University of Rochester
             benchmarked fio and provided a report
Sofia - EDI https://www.edi.works
             benchmarked the top eight memory hogs and provided reports

Can you please provide your Tested-by tags? This will ensure the credit
for your contributions.

Thanks!


Have been pounding on this "in production" on several different machines
(server, desktop, laptop) and 5.15.x without any issues, so:

Tested-by: Holger Hoffstätte <holger@xxxxxxxxxxxxxxxxxxxxxx>

Looking forward to seeing this in mainline!

cheers,
Holger





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux