[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1811191410520.150313@chino.kir.corp.google.com>
Date: Mon, 19 Nov 2018 14:16:24 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Andrea Arcangeli <aarcange@...hat.com>,
Michal Hocko <mhocko@...e.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 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.
The 4.4 kernel is almost three years old and this changes the NUMA
locality of any user of MADV_HUGEPAGE.
Although the page was merged even after my objection, we must revert it in
our own kernel because there is no userspace workaround to restore the
behavior previous to this patch absent using an MPOL_BIND mempolicy which
would have unwanted side effect of oom killing if the node is out of
memory for pages of the native size, which would be a non-starter.
[*] https://marc.info/?l=linux-kernel&m=153868420126775
Powered by blists - more mailing lists