From patchwork Wed Mar 27 06:36:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Ghiti X-Patchwork-Id: 10872783 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BA99717E0 for ; Wed, 27 Mar 2019 06:37:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A067828BA9 for ; Wed, 27 Mar 2019 06:37:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9422628D32; Wed, 27 Mar 2019 06:37:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2AC4128BA9 for ; Wed, 27 Mar 2019 06:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=3jnG+ukqrKAS9Jb+so4EAe2uGHJg4HHXBWyXTYdXrFI=; b=g1mS7pi9/toG5p p0rxqmqjFe0yJpR9tz4Satmo3v9U1U4a+ooJOAAgHlitaXB0Kw6gAKfmncSG5ONioqmywZ5xnwumf 2/AiU5MU/s6PkHASMqscsJjg8B/VvDpV1v62URsT48dCh7kRERg7HF96sKyTMYslfkTKekE9WyxNW AtypACF90AKagoismLqgn1jqkhCc/cZTGkGtYsOxzcRecuxbOZS2JO0g1N0XYxE3dmtHgFQ0K2VHn 2sNfbrmwg6OdfWOjwyeTaoimt05YbClwKECgvyEoaMX/8Z7gWw2qJLE4/P3GY9cwAggf3Wde7U6p+ 0gIzbl70mkuESzBjiebQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h92Bl-0006bE-0b; Wed, 27 Mar 2019 06:37:29 +0000 Received: from merlin.infradead.org ([2001:8b0:10b:1231::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h92Bc-0006Fe-Cr for linux-arm-kernel@bombadil.infradead.org; Wed, 27 Mar 2019 06:37:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IGSgYnXou/RBGvA6mnIJIA4AjlVL5IMIKpxYYCYDXUY=; b=le9xgmiE1JXcLs/y6VGjgx9DX5 sCHmt0KynPpG90F+R0avwaBJmQrav5nHOU9/9ZC6e88hSzCzcrqksqSFu9oNw3a6Lx7m7B10JxK9O fs5Ls/oksbyfL2RUGzhHyDcIlCm2weN1rXZj2ONy4ThpWnOZPGNmcjSC3HpsrtkGCnATJ7XdPcJCL 1i2HGt9hWw/IrPdVqrZ4cpL5x66BnmwmDx6hbwo1/pgdiwB83cmEiFE1ZqzXv3N3+SEu3/D+/FvgA y1C1EifeGaVa1Ja/ihP/AfXHHNy4Dl36EBVDxv2p4jSRHu2+SfizLPP0JlvdD8Horw/ASaQQ/d0TT zNPZIcYQ==; Received: from relay11.mail.gandi.net ([217.70.178.231]) by merlin.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h92BX-0004fC-A6 for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2019 06:37:16 +0000 Received: from alex.numericable.fr (127.19.86.79.rev.sfr.net [79.86.19.127]) (Authenticated sender: alex@ghiti.fr) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 78482100003; Wed, 27 Mar 2019 06:36:28 +0000 (UTC) From: Alexandre Ghiti To: aneesh.kumar@linux.ibm.com, mpe@ellerman.id.au, Andrew Morton , Vlastimil Babka , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S . Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , x86@kernel.org, Dave Hansen , Andy Lutomirski , Peter Zijlstra , Mike Kravetz , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v8 0/4] Fix free/allocation of runtime gigantic pages Date: Wed, 27 Mar 2019 02:36:22 -0400 Message-Id: <20190327063626.18421-1-alex@ghiti.fr> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190327_023715_589189_191FC747 X-CRM114-Status: GOOD ( 18.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexandre Ghiti Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP This series fixes sh and sparc that did not advertise their gigantic page support and then were not able to allocate and free those pages at runtime. It renames MEMORY_ISOLATION && COMPACTION || CMA condition into the more accurate CONTIG_ALLOC, since it allows the definition of alloc_contig_range function. Finally, it then fixes the wrong definition of ARCH_HAS_GIGANTIC_PAGE config that, without MEMORY_ISOLATION && COMPACTION || CMA defined, did not allow architectures to free boottime allocated gigantic pages although unrelated. Changes in v8: This (hopefully last) version is rebased against v5.1-rc2 so that it takes into account https://patchwork.ozlabs.org/patch/1047003/. This version: - factorizes gigantic_page_runtime_supported such as suggested by Christophe. - fix checkpath warning regarding the use of 'extern' - fix s390 build that does not include asm-generic/hugetlb.h And note that I did not add the reviewed-by and acked-by received in v6 since the patch differs a little. Changes in v7: I thought gigantic page support was settled at compile time, but Aneesh and Michael have just come up with a patch proving me wrong for powerpc: https://patchwork.ozlabs.org/patch/1047003/. So this version: - reintroduces gigantic_page_supported renamed into gigantic_page_runtime_supported - reintroduces gigantic page page support corresponding checks (not everywhere though: set_max_huge_pages check was redundant with __nr_hugepages_store_common) - introduces the possibility for arch to override this function by using asm-generic/hugetlb.h current semantics although Aneesh proposed something else. Changes in v6: - Remove unnecessary goto since the fallthrough path does the same and is the 'normal' behaviour, as suggested by Dave Hensen - Be more explicit in comment in set_max_huge_page: we return an error if alloc_contig_range is not defined and the user tries to allocate a gigantic page (we keep the same behaviour as before this patch), but we now let her free boottime gigantic page, as suggested by Dave Hensen - Add Acked-by, thanks. Changes in v5: - Fix bug in previous version thanks to Mike Kravetz - Fix block comments that did not respect coding style thanks to Dave Hensen - Define ARCH_HAS_GIGANTIC_PAGE only for sparc64 as advised by David Miller - Factorize "def_bool" and "depends on" thanks to Vlastimil Babka Changes in v4 as suggested by Dave Hensen: - Split previous version into small patches - Do not compile alloc_gigantic** functions for architectures that do not support those pages - Define correct ARCH_HAS_GIGANTIC_PAGE in all arch that support them to avoid useless runtime check - Add comment in set_max_huge_pages to explain that freeing is possible even without CONTIG_ALLOC defined - Remove gigantic_page_supported function across all archs Changes in v3 as suggested by Vlastimil Babka and Dave Hansen: - config definition was wrong and is now in mm/Kconfig - COMPACTION_CORE was renamed in CONTIG_ALLOC Changes in v2 as suggested by Vlastimil Babka: - Get rid of ARCH_HAS_GIGANTIC_PAGE - Get rid of architecture specific gigantic_page_supported - Factorize CMA or (MEMORY_ISOLATION && COMPACTION) into COMPACTION_CORE Alexandre Ghiti (4): sh: Advertise gigantic page support sparc: Advertise gigantic page support mm: Simplify MEMORY_ISOLATION && COMPACTION || CMA into CONTIG_ALLOC hugetlb: allow to free gigantic pages regardless of the configuration arch/arm64/Kconfig | 2 +- arch/arm64/include/asm/hugetlb.h | 4 -- arch/powerpc/include/asm/book3s/64/hugetlb.h | 5 +- arch/powerpc/platforms/Kconfig.cputype | 2 +- arch/s390/Kconfig | 2 +- arch/s390/include/asm/hugetlb.h | 8 +-- arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/x86/Kconfig | 2 +- arch/x86/include/asm/hugetlb.h | 4 -- arch/x86/mm/hugetlbpage.c | 2 +- include/asm-generic/hugetlb.h | 7 +++ include/linux/gfp.h | 4 +- mm/Kconfig | 3 ++ mm/hugetlb.c | 54 ++++++++++++++------ mm/page_alloc.c | 7 ++- 16 files changed, 67 insertions(+), 41 deletions(-)