linux-kernel - Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV

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:   Tue, 20 Nov 2018 15:53:10 -0800 (PST)
From:   David Rientjes <rientjes@...gle.com>
To:     Michal Hocko <mhocko@...nel.org>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Stefan Priebe <s.priebe@...fihost.ag>,
        Alex Williamson <alex.williamson@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Zi Yan <zi.yan@...rutgers.edu>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE
 mappings

On Tue, 20 Nov 2018, Michal Hocko wrote:

> On Mon 19-11-18 14:16:24, David Rientjes wrote:
> > On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
> > 
> > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > 
> > As I noted when this patch was originally proposed and when I nacked it[*] 
> > because it causes a 13.9% increase in remote memory access latency and up 
> > to 40% increase in remote memory allocation latency on much of our 
> > software stack that uses MADV_HUGEPAGE after mremapping the text segment 
> > to memory backed by hugepages, I don't think this is stable material.
> 
> There was a wider consensus that this is the most minimal fix for users
> who see a regression introduced by 5265047ac301 ("mm, thp: really
> limit transparent hugepage allocation to local node"). As it has been
> discussed extensively there is no universal win but we should always opt
> for the safer side which this patch is accomplishing. The changelog goes
> in length explaining them along with numbers. I am not happy that your
> particular workload is suffering but this area certainly requires much
> more changes to satisfy wider range of users.
> 
> > The 4.4 kernel is almost three years old and this changes the NUMA 
> > locality of any user of MADV_HUGEPAGE.
> 
> Yes and we have seen bug reports as we adopted this older kernel only
> now.

I think the responsible thing to do would be allow users to remain on 
their stable kernel that they know works, whether that's 4.4 or any of the 
others this is proposed for, and downgrade from any current kernel release 
that causes their workloads to have such severe regressions once they try 
a kernel with this commit.