Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5574740imu; Tue, 29 Jan 2019 23:18:33 -0800 (PST) X-Google-Smtp-Source: ALg8bN4HxBY+L2MHRo6Re/mvXvVUsvXJozLhjNNHZk8LAPYtywxhEx+pRX5QXAC9M9iFs2Au+pO+ X-Received: by 2002:a63:e344:: with SMTP id o4mr26230594pgj.158.1548832713738; Tue, 29 Jan 2019 23:18:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548832713; cv=none; d=google.com; s=arc-20160816; b=0nU8BemU33HpxFzE7vXPplfBAEXDujUhhBy27BaHZ7ExZRzem5G1uK6qsgLpc8XEEq OOcNNTmXNrEbLLe1ud0qkL+b49DpyGs7tYVnditAjTAvckucgypfmoNwXtRFOLyVLE+y XkJxNTLv6+VELiAzhuLLrdoJJ5pPqke/G1IhDbiVyRqsYB1Mir81ylzR18ZIk1l4Oc3b pW9vNvK7/ip9HkmddXlbkDeEZCWVyLBJ6hHE0dVhrDGDnhpaTAIgs67D6nW6OWZWSHUa TwLjAdGz9wODlntuGUTPXsoBRyKlzsU5PITLsv+7gdpweXzMesyOOKugg8+DZiqOunAW NG3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=mmdDNS+DHTyOMjuCvROx/E6yPyWbz3WbKEsTLrej1y0=; b=zaITcL053zYzwCryCeTS3fG2JwKFo2X2zSTrz7qJ9EP9l5MNtnRlXJZ+XvNBmd7aSo ONAqHLE4Lcoqca2XCLYjIpI3MhOpO3BbDnzJXnSYk7LeLZJE3nDLhv58Mvki7gG72zTl 1feowVYgwZc0AN6n1pUYSNK6ei69x0Mbho/5DF3eLkVNSUnYYpf2wEwl0GOwNt0rAs/I FUemDfncM/QyY3fKX4egL0mgpxmWDawaNj7xygDKmPCND0s8KAipfwh64gVaQ96CT93c W8DK1APkDKxyJ/imoxE270vcFsrPCESsqAzMxLAlLO9wHCPD+7jNB3WkQCD9YIuTJpaa Qatg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d25si730965pgd.88.2019.01.29.23.18.17; Tue, 29 Jan 2019 23:18:33 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730001AbfA3HSE (ORCPT + 99 others); Wed, 30 Jan 2019 02:18:04 -0500 Received: from mx2.suse.de ([195.135.220.15]:59584 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726368AbfA3HSD (ORCPT ); Wed, 30 Jan 2019 02:18:03 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CB835AC5B; Wed, 30 Jan 2019 07:18:01 +0000 (UTC) Date: Wed, 30 Jan 2019 08:17:59 +0100 From: Michal Hocko To: Andrea Arcangeli Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Peter Xu , Blake Caldwell , Mike Rapoport , Mike Kravetz , Mel Gorman , Vlastimil Babka , David Rientjes Subject: Re: [LSF/MM TOPIC] NUMA remote THP vs NUMA local non-THP under MADV_HUGEPAGE Message-ID: <20190130071759.GR18811@dhcp22.suse.cz> References: <20190129234058.GH31695@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190129234058.GH31695@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 29-01-19 18:40:58, Andrea Arcangeli wrote: > Hello, > > I'd like to attend the LSF/MM Summit 2019. I'm interested in most MM > topics and it's enlightening to listen to the common non-MM topics > too. > > One current topic that could be of interest is the THP / NUMA tradeoff > in subject. > > One issue about a change in MADV_HUGEPAGE behavior made ~3 years ago > kept floating around for the last 6 months (~12 months since it was > initially reported as regression through an enterprise-like workload) > and it was hot-fixed in commit > ac5b2c18911ffe95c08d69273917f90212cf5659, but it got quickly reverted > for various reasons. > > I posted some benchmark results showing that for tasks without strong > NUMA locality the __GFP_THISNODE logic is not guaranteed to be optimal > (and here of course I mean even if we ignore the large slowdown with > swap storms at allocation time that might be caused by > __GFP_THISNODE). The results also show NUMA remote THPs help > intrasocket as well as intersocket. > > https://lkml.kernel.org/r/20181210044916.GC24097@redhat.com > https://lkml.kernel.org/r/20181212104418.GE1130@redhat.com > > The following seems the interim conclusion which I happen to be in > agreement with Michal and Mel: > > https://lkml.kernel.org/r/20181212095051.GO1286@dhcp22.suse.cz > https://lkml.kernel.org/r/20181212170016.GG1130@redhat.com I am definitely interested in discussing this topic and actually wanted to propose it myself. I would add that part of the discussion was proposing a neww memory policy that would effectively enable per-vma node-reclaim like behavior. -- Michal Hocko SUSE Labs