linux-kernel - Re: [PATCH] mm: add config for readahead window

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:   Fri, 16 Mar 2018 14:26:47 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Wei Wang <wvw@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        toddpoynor@...gle.com, wei.vince.wang@...il.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Michal Hocko <mhocko@...e.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Jan Kara <jack@...e.cz>,
        Jérôme Glisse <jglisse@...hat.com>,
        Hugh Dickins <hughd@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Sherry Cheung <SCheung@...dia.com>,
        "Oliver O'Halloran" <oohall@...il.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Huang Ying <ying.huang@...el.com>,
        Dennis Zhou <dennisz@...com>,
        Pavel Tatashin <pasha.tatashin@...cle.com>,
        linux-mm <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: add config for readahead window

On Fri, Mar 16, 2018 at 1:56 PM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
>
> Increase of readahead window was proposed several times. And rejected.
> IIRC, Linus was against it.

I have never seen any valid situation that wasn't tuning for one odd
machine, usually with a horribly crappy disk setup and very little
testing of latencies or low-memory situations.

And "horribly crappy" very much tends to include "big serious
enterprise hardware" that people paid big bucks for, and that has huge
theoretical throughput for large transfers, but is pure garbage in
every other way.

So I'm still very much inclined against these kinds of things. They
need *extensive* numbers and explanations for why it's not just some
uncommon thing for one setup.

                   Linus