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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 37CD8C43381 for ; Thu, 14 Feb 2019 10:59:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 12EEE222A1 for ; Thu, 14 Feb 2019 10:59:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406352AbfBNK72 (ORCPT ); Thu, 14 Feb 2019 05:59:28 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:59843 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730148AbfBNK72 (ORCPT ); Thu, 14 Feb 2019 05:59:28 -0500 X-Originating-IP: 81.250.144.103 Received: from [10.30.1.20] (lneuilly-657-1-5-103.w81-250.abo.wanadoo.fr [81.250.144.103]) (Authenticated sender: alex@ghiti.fr) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 87261240005; Thu, 14 Feb 2019 10:59:18 +0000 (UTC) Subject: Re: [PATCH v2] hugetlb: allow to free gigantic pages regardless of the configuration To: Vlastimil Babka , Dave Hansen , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , x86@kernel.org, Dave Hansen , Andy Lutomirski , Peter Zijlstra , Alexander Viro , Mike Kravetz , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20190213192610.17265-1-alex@ghiti.fr> From: Alexandre Ghiti Message-ID: <3f694efe-c8d4-d0b0-a3eb-127d1a6b0fd0@ghiti.fr> Date: Thu, 14 Feb 2019 11:59:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 02/14/2019 10:52 AM, Vlastimil Babka wrote: > On 2/13/19 8:30 PM, Dave Hansen wrote: >>> -#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA) >>> +#ifdef CONFIG_COMPACTION_CORE >>> static __init int gigantic_pages_init(void) >>> { >>> /* With compaction or CMA we can allocate gigantic pages at runtime */ >>> diff --git a/fs/Kconfig b/fs/Kconfig >>> index ac474a61be37..8fecd3ea5563 100644 >>> --- a/fs/Kconfig >>> +++ b/fs/Kconfig >>> @@ -207,8 +207,9 @@ config HUGETLB_PAGE >>> config MEMFD_CREATE >>> def_bool TMPFS || HUGETLBFS >>> >>> -config ARCH_HAS_GIGANTIC_PAGE >>> +config COMPACTION_CORE >>> bool >>> + default y if (MEMORY_ISOLATION && MIGRATION) || CMA >> This takes a hard dependency (#if) and turns it into a Kconfig *default* >> that can be overridden. That seems like trouble. >> >> Shouldn't it be: >> >> config COMPACTION_CORE >> def_bool y >> depends on (MEMORY_ISOLATION && MIGRATION) || CMA > Agreed. Also I noticed that it now depends on MIGRATION instead of > COMPACTION. That intention is correct IMHO, but will fail to > compile/link when both COMPACTION and CMA are disabled, and would need > more changes in mm/internal.h and mm/compaction.c (possibly just > replacing CMA in all "if defined CONFIG_COMPACTION || defined > CONFIG_CMA" instances with COMPACTION_CORE, but there might be more > problems, wanna try? :) Let's be honest, that's a "typo" :) Migration is logical to me but that's because I don't know much about compaction. Thanks for noticing it. I'll take a look at what you propose to do too. > > Also, I realized that COMPACTION_CORE is a wrong name, sorry about that. > What the config really provides is alloc_contig_range(), so it should be > named either CONFIG_CMA_CORE (as it provides contiguous memory > allocation, but not the related reservation and accounting), or > something like CONFIG_CONTIG_ALLOC. I would also move it from fs/Kconfig > to mm/Kconfig. No problem, I was not inspired either. I'll send a v3 with the renaming you propose. > Thanks! Thank you. Alex