Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1044824imj; Wed, 13 Feb 2019 23:51:07 -0800 (PST) X-Google-Smtp-Source: AHgI3IaMoESG7I9SjBqnwtY3DaVHpvjFE3dnoApQ3nn0tHQPm4jyOnoxfqmi6X+rhF2o28yKbU8m X-Received: by 2002:a65:6483:: with SMTP id e3mr2460729pgv.273.1550130667264; Wed, 13 Feb 2019 23:51:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550130667; cv=none; d=google.com; s=arc-20160816; b=Wir63FlrAFZnf+gEdKi5GvvdtV9Wo/kBYVxU1mBFejq9u3IRuiEtdhph9ozLhkTrQ3 aLilaaMlVpIh2DF+0A9Spv3Y3by0AK/ZqWT2gBhi2GdEQXiNWNO073sz6AM+4UmU7d/N FZQkXupnDrur6Pwp3C3nwD6ORqukxPgCmcwXZIYakOqVgQ0u/gEYJi+5UzUdPq2s5HbC 9oKk9UKuqiJqxRPLI2NBhl5Vy0vXw/hzTWWJTUrAxvhTqbwRSU4zaNASTo8yF14ANdCx 785K2/soWm3PQa7Yqb4h09USbuHx24RoyOfz+3d8q+PBlv623+H96aWj9q2WmZosxtJu 83fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Q6vEWTW35opmCQKNqyHy4VQAtcYCXhbRYGzBwGpyjhY=; b=znSJiw+vXQZta77q1NSPP7LPzUwzRBigI9y1uP7lN2XuluEnuEw5nHs760RTW6hv5T oKYZ+VkviiAEBkzGkfTFZWwXRRyNTVUyQ1R6G2q1y+OiWGJt9LnyEa2Cy1mlMpGjXrbR MiuLf3we0LgGUgnk/zfULktijZWTUXEUFiM6ydHuouRQJMwJBq+dmhuCFye3Vh9VD7cN +gDZGu0OjY6mKMh+mta0WbzlfuMHrOM1PVjLpYZs5Ns5jnpb9k8ZgJIvutf75OvvDUwC b5gZVI1JSo9mySo4a9VaKqZM07h76z7wgac7PwiwZLDOOoLjyiErpBWnHu464ILXwRHs pROA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u63si1744322pfi.196.2019.02.13.23.50.51; Wed, 13 Feb 2019 23:51:07 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394347AbfBMTWi (ORCPT + 99 others); Wed, 13 Feb 2019 14:22:38 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:46671 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731511AbfBMTWh (ORCPT ); Wed, 13 Feb 2019 14:22:37 -0500 Received: from [192.168.0.11] (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 0F08B100005; Wed, 13 Feb 2019 19:22:21 +0000 (UTC) Subject: Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration To: Vlastimil Babka , 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, 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 Cc: linux-riscv@lists.infradead.org, hch@infradead.org References: <20190117183953.5990-1-aghiti@upmem.com> <16a6209c-868b-8fd5-a70a-6e0e1ecb62d4@suse.cz> From: Alex Ghiti Message-ID: <7801de9c-9a8c-fb56-442a-6e530e52e0d8@ghiti.fr> Date: Wed, 13 Feb 2019 14:22:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <16a6209c-868b-8fd5-a70a-6e0e1ecb62d4@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: sv-FI Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/13/19 6:27 AM, Vlastimil Babka wrote: > On 1/17/19 7:39 PM, Alexandre Ghiti wrote: >> From: Alexandre Ghiti >> >> On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but >> that support gigantic pages, boottime reserved gigantic pages can not be >> freed at all. This patchs simply enables the possibility to hand back >> those pages to memory allocator. >> >> This commit then renames gigantic_page_supported and >> ARCH_HAS_GIGANTIC_PAGE to make them more accurate. Indeed, those values >> being false does not mean that the system cannot use gigantic pages: it >> just means that runtime allocation of gigantic pages is not supported, >> one can still allocate boottime gigantic pages if the architecture supports >> it. >> >> Signed-off-by: Alexandre Ghiti > I'm fine with the change, but wonder if this can be structured better in a way > which would remove the duplicated "if (MEMORY_ISOLATION && COMPACTION) || CMA" > from all arches, as well as the duplicated > gigantic_page_runtime_allocation_supported() Yeah, totally, we can factorize more than what I did. I prepared a v2 of this patch that does exactly that: remove the triplet from arch specific code and the duplicated gigantic_page_runtime_allocation_supported. > something like: > > - "select ARCH_HAS_GIGANTIC_PAGE" has no conditions, it just says the arch can > support them either at boottime or runtime (but runtime is usable only if other > conditions are met) And the v2 gets rid of ARCH_HAS_GIGANTIC_PAGE totally since it is not needed by arch to advertise the fact they support gigantic page, actually, when selected, it really just means that an arch has the means to allocate runtime gigantic page: it is equivalent to (MEMORY_ISOLATION && COMPACTION) || CMA. > - gigantic_page_runtime_allocation_supported() is a function that returns true > if ARCH_HAS_GIGANTIC_PAGE && ((MEMORY_ISOLATION && COMPACTION) || CMA) and > there's a single instance, not per-arch. > - code for freeing gigantic pages can probably still be conditional on > ARCH_HAS_GIGANTIC_PAGE > > BTW I wanted also to do something about the "(MEMORY_ISOLATION && COMPACTION) || > CMA" ugliness itself, i.e. put the common parts behind some new kconfig > (COMPACTION_CORE ?) and expose it better to users, but I can take a stab on that > once the above part is settled. > Vlastimil I send the v2 right away, if you can take a look Vlastimil, that would be great. Note that Andrew already picked this patch in its tree, I'm not sure how to proceed. Thanks for your remarks ! Alex