linux-kernel - Re: [rfc] mm, hugetlb: allow hugepage allocations to excessively reclaim

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-=wgTqcdgyWjsj0Kip-2GLqx+dkWGoUTKmxCT3VN7Ya2bSg@mail.gmail.com>
Date:   Wed, 2 Oct 2019 16:37:57 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: [rfc] mm, hugetlb: allow hugepage allocations to excessively reclaim

On Wed, Oct 2, 2019 at 4:03 PM David Rientjes <rientjes@...gle.com> wrote:
>
> Since hugetlb allocations have explicitly preferred to loop and do reclaim
> and compaction, exempt them from this new behavior at least for the time
> being.  It is not shown that hugetlb allocation success rate has been
> impacted by commit b39d0ee2632d but hugetlb allocations are admittedly
> beyond the scope of what the patch is intended to address (thp
> allocations).

I'd like to see some numbers to show that this special case makes sense.

I understand the "this is what it used to do, and hugetlbfs wasn't the
intended recipient of the new semantics", and I don't think the patch
is wrong.

But at the same time, we do know that swap storms happen for other
loads, and if we say "hugetlbfs is different" then there should at
least be some rationale for why it's different other than "history".
Some actual "yes, we _want_ the possibile swap storms, because load
XYZ".

And I don't mean microbenchmark numbers for "look, behavior changed".
I mean "look, this is a real load, and now it runs X% slower because
it relied on this hugetlbfs behavior".

               Linus