Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 19 Nov 2018 14:16:24 -0800 (PST)
From:   David Rientjes <rientjes@google.com>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Andrea Arcangeli <aarcange@redhat.com>,
        Michal Hocko <mhocko@suse.com>,
        Stefan Priebe <s.priebe@profihost.ag>,
        Alex Williamson <alex.williamson@redhat.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Zi Yan <zi.yan@cs.rutgers.edu>,
        Vlastimil Babka <vbabka@suse.cz>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE
 mappings
In-Reply-To: <20181119162643.032920932@linuxfoundation.org>
Message-ID: <alpine.DEB.2.21.1811191410520.150313@chino.kir.corp.google.com>
References: <20181119162630.031306128@linuxfoundation.org> <20181119162643.032920932@linuxfoundation.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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