Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2165292ybd; Mon, 24 Jun 2019 01:47:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqwSlDOZ0SeJrHJrUSD264urBxH+cADQBcd2KyN22YRAo603APdLpEYYORrUkMPF8NFIqh7Q X-Received: by 2002:a63:f50d:: with SMTP id w13mr31765144pgh.411.1561366057974; Mon, 24 Jun 2019 01:47:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561366057; cv=none; d=google.com; s=arc-20160816; b=QeYrqQMpWziDtj10ZgODYP2/cQvmtCnULPPTuad6pne9vZWLVOiGaS48cmGS+LKDoS HHlyEcdRK4h308X8zWd8H0XBN+sMAzTWHFBdowaxVssr18Y1OwBhJWxszlqnY+VXhL04 ljDls92MVtx+ogpeUIcpuEC8+yA57IFpaWAp+cc61Y6ea34glgejlciHCUQnDUdN9Vln ZDKVADpOBirbOrdLHBA3va1MJekmm4fxChDg1tfCPCrEqyYgxL+jQcb/iN64FNklfjmB kuOj5PWcsCODFq4bBSV+M/hmgmFHffugENlCHWJcuQ90l4GuvByFq0rVoL8LHevYKDo5 mbPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=BRZq4S2DDLhQNM3xsu962oaD4iXVjqObF4JAZ5MfzjE=; b=pMWNxdkFwTWInp5SvXiqpQBh1zlbfO1ZlMl48ZnYS/oCXjBV2NFNjKHAz8WL5hsVGx NnM58filOrz2HXmapwMRA0wX61gPjuprXbc+7E8v5MKK7j3JvLVU7vZnwqroMS//Tbk/ 3VaZ+kS6xp7BuLc88OSeLc8O77OmW+xkTYJVdFo3JpeKjDVjGedjtu5pQ1PMoyP4Twlx B9hYFR/vPB8azNlHVYSX2wZ4yH7Okt6FFwwMQBAl8x+Wz73bZkuToLZEO1OBp0nwrXRP CE4sjIgZXUoEWlaaUOUCQJXYiQJYhER/tOhYmse/Bgt0ZJFnSjpcnPjeyZ63WovbnxQb OE/A== 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 x9si9229922pll.347.2019.06.24.01.47.22; Mon, 24 Jun 2019 01:47:37 -0700 (PDT) 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 S1727971AbfFXI0N (ORCPT + 99 others); Mon, 24 Jun 2019 04:26:13 -0400 Received: from foss.arm.com ([217.140.110.172]:43574 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726077AbfFXI0N (ORCPT ); Mon, 24 Jun 2019 04:26:13 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 81D042B; Mon, 24 Jun 2019 01:26:12 -0700 (PDT) Received: from [10.162.41.123] (p8cg001049571a15.blr.arm.com [10.162.41.123]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5533C3F71E; Mon, 24 Jun 2019 01:26:10 -0700 (PDT) Subject: Re: [PATCH] mm/hugetlb: allow gigantic page allocation to migrate away smaller huge page To: Pingfan Liu Cc: linux-mm@kvack.org, Mike Kravetz , Oscar Salvador , David Hildenbrand , Andrew Morton , LKML References: <1561350068-8966-1-git-send-email-kernelfans@gmail.com> <216a335d-f7c6-26ad-2ac1-427c8a73ca2f@arm.com> From: Anshuman Khandual Message-ID: <5fe6bd80-7801-d81e-7a5e-a90afb697c33@arm.com> Date: Mon, 24 Jun 2019 13:56:34 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/24/2019 11:40 AM, Pingfan Liu wrote: > On Mon, Jun 24, 2019 at 1:16 PM Anshuman Khandual > wrote: >> >> >> >> On 06/24/2019 09:51 AM, Pingfan Liu wrote: >>> The current pfn_range_valid_gigantic() rejects the pud huge page allocation >>> if there is a pmd huge page inside the candidate range. >>> >>> But pud huge resource is more rare, which should align on 1GB on x86. It is >>> worth to allow migrating away pmd huge page to make room for a pud huge >>> page. >>> >>> The same logic is applied to pgd and pud huge pages. >> >> The huge page in the range can either be a THP or HugeTLB and migrating them has >> different costs and chances of success. THP migration will involve splitting if >> THP migration is not enabled and all related TLB related costs. Are you sure >> that a PUD HugeTLB allocation really should go through these ? Is there any > PUD hugetlb has already driven out PMD thp in current. This patch just > want to make PUD hugetlb survives PMD hugetlb. You are right. PageHuge() is true only for HugeTLB pages unlike PageTransHuge() which is true for both HugeTLB and THP pages. So the current code does migrate the THP out in order to allocate a gigantic HugeTLB. While here just wondering should not we exclude THP as well unless it supports ARCH_HAS_THP_MIGRATION.