linux-kernel - Re: [PATCH v8 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]

Message-ID: <CAHk-=wgwgqJMyxbrxa-mY3cYh--BZ5JKDieVc=RfXR1mdqsYkQ@mail.gmail.com>
Date:   Tue, 8 Mar 2022 16:29:33 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Yu Zhao <yuzhao@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Aneesh Kumar <aneesh.kumar@...ux.ibm.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>,
        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 Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Kernel Page Reclaim v2 <page-reclaim@...gle.com>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH v8 00/14] Multi-Gen LRU Framework

On Tue, Mar 8, 2022 at 4:15 PM Yu Zhao <yuzhao@...gle.com> wrote:
>
> This sounds self-serving: our data centers want them, so I had to try.

Heh. I'm not opposed to putting them back in, but if/when we merge the
multi-gen LRU code, I really want people to be all testing the same
thing.

I also think that if we put them back in, that should come with

 (a) performance numbers for the different cases

 (b) hard guidance of what the numbers should be, and under what
circumstances (ie giving the user enough information that he *can*
answer the question for his configuration)

 (c) some thought about perhaps making them possibly more dynamic than
a hardcoded build-time value (assuming the numbers show that it's
worth doing in the first place, of course)

so I think that the support for the concept can/should be left in, but
I think that kind of fancy "I want more generations or fewer
tiers-per-generation because of XYZ" needs to be a separate issue with
more explanation from the initial "This multi-gen LRU gives better
performance" merge.

Because as-is, I don't think those config options had nearly enough
information associated with them to merit them existing.

                  Linus