From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE55827145F for ; Wed, 11 Feb 2026 01:12:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770772373; cv=none; b=ojVyTk2HWNLqM0GS9uucdOBH7c1/xD5fWD9j68/RspzcE/hTiAiFia1Wj9BQY5f+pf/i+bM4TBDPB8WeXr8+rz3IM87L3hHhj3azdtkr1ijkcpg8cQWHTDpnaJfXcmzNLENggsiJXE2tP18W1yVJzvUS7PFDfp8JNBoYsDdZunM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770772373; c=relaxed/simple; bh=bbMc6gArvCXlP381vZVczX9orYJK6UKBvAyP3j/DXt0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NiwVjhOOc6Hw71VPrxmL8HdOSHo/ML+nW1Ymw13iFn+W6rnD0pwtQ1yg0eA6o61MaWWzcGhcKhHnrd8G3r3fAcfq9+rea/GvIU6gaJScNzNS0UBva+h5/r9XTeI0y/pju+Slpiimn3Tidwaqxx8+tNGWLK2dk16oUkccIFtzEfw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=i8nAa+au; arc=none smtp.client-ip=115.124.30.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="i8nAa+au" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1770772362; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=faQqNuYtBPQaP3ZQXG1razFHoF3o8CJE3mR/YmkHui8=; b=i8nAa+auUf8wYBuWzrCzulaOVqCTbjNxbpVf0N1HIzqSSW5yA5a/vC7GCMIxA1uvG/DA87e0K9rnzYs9XUkMVKUKAnLrWkIjd7DgECSd3hYxg9mld28NXZ2IIJsmIlYFQE33tK1r+TBF3cl0YKx8d6D83OuXIwfY1wBrx/9jmLg= Received: from 30.74.144.106(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Wz-u6Mf_1770772361 cluster:ay36) by smtp.aliyun-inc.com; Wed, 11 Feb 2026 09:12:42 +0800 Message-ID: Date: Wed, 11 Feb 2026 09:12:41 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/11] mm: thp: always enable mTHP support To: Luiz Capitulino , linux-kernel@vger.kernel.org, linux-mm@kvack.org, david@kernel.org Cc: ryan.roberts@arm.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com References: <29e8dfc2772af4b6e0db24134ca3563ec422b91a.1770675272.git.luizcap@redhat.com> <0c0886d5-2561-40e4-94e9-6fca15f25127@redhat.com> From: Baolin Wang In-Reply-To: <0c0886d5-2561-40e4-94e9-6fca15f25127@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/10/26 9:28 PM, Luiz Capitulino wrote: > On 2026-02-10 04:56, Baolin Wang wrote: >> >> >> On 2/10/26 6:14 AM, Luiz Capitulino wrote: >>> If PMD-sized pages are not supported on an architecture (ie. the >>> arch implements arch_has_pmd_leaves() and it returns false) then the >>> current code disables all THP, including mTHP. >>> >>> This commit fixes this by allowing mTHP to be always enabled for all >>> archs. When PMD-sized pages are not supported, its sysfs entry won't be >>> created and their mapping will be disallowed at page-fault time. >>> >>> Similarly, this commit implements the following changes for shmem: >>> >>>   - In shmem_allowable_huge_orders(): drop the pgtable_has_pmd_leaves() >>>     check so that mTHP sizes are considered >>>   - In shmem_alloc_and_add_folio(): don't consider PMD and PUD orders >>>     when PMD-sized pages are not supported by the CPU >>> >>> Signed-off-by: Luiz Capitulino >>> --- >>>   mm/huge_memory.c | 11 +++++++---- >>>   mm/shmem.c       |  4 +++- >>>   2 files changed, 10 insertions(+), 5 deletions(-) >>> >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>> index 1e5ea2e47f79..882331592928 100644 >>> --- a/mm/huge_memory.c >>> +++ b/mm/huge_memory.c >>> @@ -115,6 +115,9 @@ unsigned long __thp_vma_allowable_orders(struct >>> vm_area_struct *vma, >>>       else >>>           supported_orders = THP_ORDERS_ALL_FILE_DEFAULT; >>> +    if (!pgtable_has_pmd_leaves()) >>> +        supported_orders &= ~(BIT(PMD_ORDER) | BIT(PUD_ORDER)); >>> + >>>       orders &= supported_orders; >>>       if (!orders) >>>           return 0; >>> @@ -122,7 +125,7 @@ unsigned long __thp_vma_allowable_orders(struct >>> vm_area_struct *vma, >>>       if (!vma->vm_mm)        /* vdso */ >>>           return 0; >>> -    if (!pgtable_has_pmd_leaves() || vma_thp_disabled(vma, vm_flags, >>> forced_collapse)) >>> +    if (vma_thp_disabled(vma, vm_flags, forced_collapse)) >>>           return 0; >>>       /* khugepaged doesn't collapse DAX vma, but page fault is fine. */ >>> @@ -806,6 +809,9 @@ static int __init hugepage_init_sysfs(struct >>> kobject **hugepage_kobj) >>>       } >>>       orders = THP_ORDERS_ALL_ANON | THP_ORDERS_ALL_FILE_DEFAULT; >>> +    if (!pgtable_has_pmd_leaves()) >>> +        orders &= ~(BIT(PMD_ORDER) | BIT(PUD_ORDER)); >> >> I think you should also handle the 'huge_anon_orders_inherit' setting >> in this function if pgtable_has_pmd_leaves() returns false. Shmem as >> well. >> >> if (!anon_orders_configured) >>      huge_anon_orders_inherit = BIT(PMD_ORDER); > > Good catch. So, would you agree that should set it to BIT(PMD_ORDER - 1) > in this case? From the documentation: " By default, PMD-sized hugepages have enabled="inherit" and all other hugepage sizes have enabled="never". " So if pgtable_has_pmd_leaves() returns false, IMO, we should just skip setting the PMD-sized order for huge_anon_orders_inherit. What I mean is: if (!anon_orders_configured && pgtable_has_pmd_leaves()) huge_anon_orders_inherit = BIT(PMD_ORDER);