From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D60D5C5ACCC for ; Tue, 16 Oct 2018 22:37:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A286021471 for ; Tue, 16 Oct 2018 22:37:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A286021471 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727353AbeJQG3u (ORCPT ); Wed, 17 Oct 2018 02:29:50 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:47616 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727184AbeJQG3u (ORCPT ); Wed, 17 Oct 2018 02:29:50 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 63DBC2B40; Tue, 16 Oct 2018 22:37:16 +0000 (UTC) Date: Tue, 16 Oct 2018 15:37:15 -0700 From: Andrew Morton To: Mel Gorman Cc: David Rientjes , Andrea Arcangeli , Michal Hocko , Vlastimil Babka , Andrea Argangeli , Zi Yan , Stefan Priebe - Profihost AG , "Kirill A. Shutemov" , linux-mm@kvack.org, LKML , Stable tree Subject: Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings Message-Id: <20181016153715.b40478ff2eebe8d6cf1aead5@linux-foundation.org> In-Reply-To: <20181016074606.GH6931@suse.de> References: <20181005232155.GA2298@redhat.com> <20181009094825.GC6931@suse.de> <20181009122745.GN8528@dhcp22.suse.cz> <20181009130034.GD6931@suse.de> <20181009142510.GU8528@dhcp22.suse.cz> <20181009230352.GE9307@redhat.com> <20181015154459.e870c30df5c41966ffb4aed8@linux-foundation.org> <20181016074606.GH6931@suse.de> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 Oct 2018 08:46:06 +0100 Mel Gorman wrote: > On Mon, Oct 15, 2018 at 03:44:59PM -0700, Andrew Morton wrote: > > On Mon, 15 Oct 2018 15:30:17 -0700 (PDT) David Rientjes wrote: > > > > > At the risk of beating a dead horse that has already been beaten, what are > > > the plans for this patch when the merge window opens? > > > > I'll hold onto it until we've settled on something. Worst case, > > Andrea's original is easily backportable. > > > > I consider this to be an unfortunate outcome. On the one hand, we have a > problem that three people can trivially reproduce with known test cases > and a patch shown to resolve the problem. Two of those three people work > on distributions that are exposed to a large number of users. On the > other, we have a problem that requires the system to be in a specific > state and an unknown workload that suffers badly from the remote access > penalties with a patch that has review concerns and has not been proven > to resolve the trivial cases. In the case of distributions, the first > patch addresses concerns with a common workload where on the other hand > we have an internal workload of a single company that is affected -- > which indirectly affects many users admittedly but only one entity directly. > > At the absolute minimum, a test case for the "system fragmentation incurs > access penalties for a workload" scenario that could both replicate the > fragmentation and demonstrate the problem should have been available before > the patch was rejected. With the test case, there would be a chance that > others could analyse the problem and prototype some fixes. The test case > was requested in the thread and never produced so even if someone were to > prototype fixes, it would be dependant on a third party to test and produce > data which is a time-consuming loop. Instead, we are more or less in limbo. > OK, thanks. But we're OK holding off for a few weeks, yes? If we do that we'll still make it into 4.19.1. Am reluctant to merge this while discussion, testing and possibly more development are ongoing.