linux-kernel - Re: [PATCH v10 00/14] Multi-Gen LRU Framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 Apr 2022 21:24:27 -0600
From:   Yu Zhao <yuzhao@...gle.com>
To:     Stephen Rothwell <sfr@...hwell.id.au>,
        Linux-MM <linux-mm@...ck.org>
Cc:     Andi Kleen <ak@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Aneesh Kumar <aneesh.kumar@...ux.ibm.com>,
        Barry Song <21cnbao@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Hillf Danton <hdanton@...a.com>, Jens Axboe <axboe@...nel.dk>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Mel Gorman <mgorman@...e.de>,
        Michael Larabel <Michael@...haellarabel.com>,
        Michal Hocko <mhocko@...nel.org>,
        Mike Rapoport <rppt@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Will Deacon <will@...nel.org>,
        Ying Huang <ying.huang@...el.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Kernel Page Reclaim v2 <page-reclaim@...gle.com>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH v10 00/14] Multi-Gen LRU Framework

On Wed, Apr 6, 2022 at 9:15 PM Yu Zhao <yuzhao@...gle.com> 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 [22][23][24], 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 current
>    active/inactive LRU.

Hi Stephen,

Can you please include this patchset in linux-next? Git repo for you to fetch:

https://linux-mm.googlesource.com/mglru for-linux-next

My goal is to get additional test coverage before I send a pull
request for 5.19 to Linus.

I've explored all avenues, but ultimately I've failed to rally
substantial support from the MM stakeholders [1]. There are no pending
technical issues against this patchset [2]. What is more concerning
are the fundamental disagreements on priorities, methodologies, etc.
that are not specific to this patchset and have been hindering our
progress as a collective. (Cheers to the mutual dissatisfaction.)

While we plan to discuss those issues during the LSFMM next month, it
doesn't seem reasonable to leave this patchset hanging in the air,
since it has reached its maturity a while ago and there are strong
demands from downstream kernels as well as a large user base. Thus I
sent that pull request to Linus a couple of weeks ago, implying that
he would have to make the final decision soon.

I hope this gives enough background about what's been going on with
this patchset. If you decide to take it and it causes you any
troubles, please feel free to yell at me.

Thanks!

[1] https://lore.kernel.org/r/20220104202227.2903605-1-yuzhao@google.com/
[2] https://lore.kernel.org/r/20220326010003.3155137-1-yuzhao@google.com/