From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (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 2F484342CB2 for ; Tue, 10 Feb 2026 09:56:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770717382; cv=none; b=Gta3AWmhPV5cmKXFS1kms+dp4oCP1BOXdIr72BBs2EVsj1cKA0fUJtMdBjW+Xsi3qdEX3X/8xfkEstZ/3IaOGtB0Pfgewu+/xZx8zU6vE7BsMMPfiwMf22Ek0VhqDtmLRoTSP9/vCqCvAYMtZ7XFG1lKx4EdVwWc6GWlj78RxnE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770717382; c=relaxed/simple; bh=BRFhnkjcIKiNm1wjeT1Rh+auXaLbW4D0/0sA+hj7Oww=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WueyAizOpf9xXOmyKelMgRIC4EDwfYkVxBbrjdVEYadrrB+GfM4+A5g8jGyeF0/F+iTPt6V0Qs7cdp3iZ3v4nUkYrKH7KjMMEPD6reFAu3az1f5MxBDLqhWjuvYE1xLRrbXtklfb+3gjDaDL3t0B9GQObukUDPHoKnyaxdQyyU0= 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=XOq1ttxw; arc=none smtp.client-ip=115.124.30.113 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="XOq1ttxw" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1770717371; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=g3w4Ro/Mrn1bvyLjMw2VNSGjYzqSkpMN6eH9+J0A5QY=; b=XOq1ttxwVQIyNli82K/XkCXV+22Zzobh7gE73ayCNGbZO+HvQ4E4CNTtbig0a6GMtX2ytSo9CQdM98V9YPbXrQG3HgJ2ytTXsvd/PCrqrLfZdbGeka+T3Qrr6nuRUMVWQGe8H9c/A4meVdofAzK8bnxAZsvLrj0iqo8GHcnH3B8= Received: from 30.74.144.109(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WyyoplG_1770717371 cluster:ay36) by smtp.aliyun-inc.com; Tue, 10 Feb 2026 17:56:11 +0800 Message-ID: Date: Tue, 10 Feb 2026 17:56:09 +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> From: Baolin Wang In-Reply-To: <29e8dfc2772af4b6e0db24134ca3563ec422b91a.1770675272.git.luizcap@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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); > + > order = highest_order(orders); > while (orders) { > thpsize = thpsize_create(order, *hugepage_kobj); > @@ -905,9 +911,6 @@ static int __init hugepage_init(void) > int err; > struct kobject *hugepage_kobj; > > - if (!pgtable_has_pmd_leaves()) > - return -EINVAL; > - > /* > * hugepages can't be allocated by the buddy allocator > */ > diff --git a/mm/shmem.c b/mm/shmem.c > index 1c98e84667a4..cb325d1e2d1e 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -1827,7 +1827,7 @@ unsigned long shmem_allowable_huge_orders(struct inode *inode, > vm_flags_t vm_flags = vma ? vma->vm_flags : 0; > unsigned int global_orders; > > - if (!pgtable_has_pmd_leaves() || (vma && vma_thp_disabled(vma, vm_flags, shmem_huge_force))) > + if (vma && vma_thp_disabled(vma, vm_flags, shmem_huge_force)) > return 0; > > global_orders = shmem_huge_global_enabled(inode, index, write_end, > @@ -1935,6 +1935,8 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf, > > if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) > orders = 0; > + else if (!pgtable_has_pmd_leaves()) > + orders &= ~(BIT(PMD_ORDER) | BIT(PUD_ORDER)); Moving this check into shmem_allowable_huge_orders() would be more appropriate. > > if (orders > 0) { > suitable_orders = shmem_suitable_orders(inode, vmf,