Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752405AbdI2Ozj (ORCPT ); Fri, 29 Sep 2017 10:55:39 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:34063 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751920AbdI2Ozh (ORCPT ); Fri, 29 Sep 2017 10:55:37 -0400 X-Google-Smtp-Source: AOwi7QAOm6vshcQNI9dnMpt3Cw3lRNxCDSdpjkKCb72Ie+8yBVr85hsvaF+IdcHjyQlDwScGiUywNA== Date: Fri, 29 Sep 2017 16:55:29 +0200 From: Alexandru Moise <00moses.alexander00@gmail.com> To: "Kirill A. Shutemov" Cc: akpm@linux-foundation.org, mhocko@suse.com, aneesh.kumar@linux.vnet.ibm.com, n-horiguchi@ah.jp.nec.com, mike.kravetz@oracle.com, khandual@linux.vnet.ibm.com, punit.agrawal@arm.com, gerald.schaefer@de.ibm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/madvise: enable soft offline of HugeTLB pages at PUD level Message-ID: <20170929145529.GA1659@gmail.com> References: <20170913101047.GA13026@gmail.com> <20170929135554.6cz7lpjn7gepmlf4@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170929135554.6cz7lpjn7gepmlf4@node.shutemov.name> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1808 Lines: 50 On Fri, Sep 29, 2017 at 04:55:54PM +0300, Kirill A. Shutemov wrote: > On Wed, Sep 13, 2017 at 12:10:47PM +0200, Alexandru Moise wrote: > > since 94310cb we've been able to soft offline 1G hugepages at the PGD > > level, however x86_64 gigantic hugepages are at the PUD level so we > > should add an extra check to account for hstate order at PUD level. > > Have you tested other cases affected by the change? It allows migration of > 1G pages in general, which might be problematic. Yes true, I could have done a better job explaining this in the commit message. > > It also makes these pages allocated with GFP_HIGHUSER_MOVABLE instead of > GFP_HIGHUSER. Any side effects there we should consider? Well, it makes hugepages_treat_as_movable sysctl pointless for one. Perhaps the below patch would be a good idea, to make this behavior optional rather. ../Alex > > > I'm not sure if this also applies to 5 level page tables on x86_64 > > however. Tested with 4 level pagetable. > > There's nothing changed in this regard in 5-level paging mode. PUD is > still one gig and there are no new page sizes. > > -- > Kirill A. Shutemov --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 424b0ef08a60..ab28de0122af 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -926,7 +926,7 @@ static struct page *dequeue_huge_page_nodemask(struct hstate *h, gfp_t gfp_mask, /* Movability of hugepages depends on migration support. */ static inline gfp_t htlb_alloc_mask(struct hstate *h) { - if (hugepages_treat_as_movable || hugepage_migration_supported(h)) + if (hugepages_treat_as_movable && hugepage_migration_supported(h)) return GFP_HIGHUSER_MOVABLE; else return GFP_HIGHUSER; -- 2.14.2