From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 AD6273E0C69 for ; Mon, 13 Apr 2026 15:39:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776094784; cv=none; b=Hyk5DQ00CRAnftdY7Y+87RkOza48Tc4bKG6X2xZ1r0mcX9ivdi67RAMp/XrW80d8eoOFptuUB2XkWv+jXpax0CAmoJcDieXdsbBsba0KeHkM1ywuySXqtbf8Wj0S1OEkpoKHnvMJeUpKhwTKfyfvG/rDKXXpW2+z6hNQ9weo1tw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776094784; c=relaxed/simple; bh=HTwOtIiuh6sLAXgNZ9sqHPO2S3AhN+OSveibWJe5j08=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RfvrviZh/nPlJReTcIVxm22aKO5ZnICDBpvd2N2JKD2fUOJ3AMp80iyi+u/uSK5AXXRbkxKPHIEbSuNANzYbrfy7kpC3IYGDvKqf1WDSL1FQCF3+0OMNCn9Rkz4VmY8oGgYig8zKnPoYK3qDxNiQAd9LsUnX2sGUl9ca/irlZxM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QaPx43G0; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QaPx43G0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776094781; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHZkKQhb0KBgrbbqGFooXSKLcTZ9GYrV66wxni4Hy6I=; b=QaPx43G0wFKx49UbaBBhA8PG39CagMYlIXImPsqLdSN5rQlW1l89j17pDtBA03XnN9KRUs tEVUVazjQpPQZOzCLzsEmQ6igjg9jkKBoPw27Nqb33XPXFU2kw6a1luNdVsFWQxkBRxn51 l6c2ugS7apTfOLW0O/KAXk/Dzen1O8E= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-693-DPgN26R7PxGy0tWS6_V9KQ-1; Mon, 13 Apr 2026 11:39:40 -0400 X-MC-Unique: DPgN26R7PxGy0tWS6_V9KQ-1 X-Mimecast-MFC-AGG-ID: DPgN26R7PxGy0tWS6_V9KQ_1776094780 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-8ac04b2fc4eso125381366d6.0 for ; Mon, 13 Apr 2026 08:39:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776094779; x=1776699579; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LHZkKQhb0KBgrbbqGFooXSKLcTZ9GYrV66wxni4Hy6I=; b=kBHQ2pJcEXzR0wu+qjVX+nXwrOAUcZUHPSdrNbRwrdGaky2+35SJ3SmdLD//r2/HBE Y/AGp8SiHuJwauohLfai2GcAf+bOmGbKItwyjrPK66GffVn4hs9w7YJzjZy5KRPLh2Uo BcLU4yrS5ka7s3RPFKRqa0xngLTd/dJ1sWWr6IZVC8qnHF9ebmic0K5ccDECE+v+eDL2 GBJUBQEJ3NHRgpLrNofdl7IVYj3fj8Z+d0q4SG/iPUPaelsPnyHg3OHftqnpbxtJWbyH yXIfFkV85xUGnRFf/dEDc3vSIZuZz1PX4eYfk+yqxiGtG6Bu1bSSs/Fc7YOicHW+cEEK dw3Q== X-Forwarded-Encrypted: i=1; AFNElJ+ZU0wUx/DWhl/95UX74lJijEo819drlDo168H/FiVGqR3NhC1oCVJv0tqqVO5h/r6ayRmi8aMHJqxTC1k=@vger.kernel.org X-Gm-Message-State: AOJu0YzEF44HZZuScgT5nqYe+1oIYbBSI0lU7K4p/xhLs319kUiKKwYL i8pDrgjQoKvaWqobNhTlwte85FPaTonC6g3mmDYCrEq3uz3R2Xs5cgyrdYAI2N69Uo1bjexyqxL dCkO+LJOOM2N64RWAorQZKHHF5EMdPlAyvafIG7nmwTQG95gGHThqP7L3vitBc8Zhbw== X-Gm-Gg: AeBDiesS66GrmWyt5J5+kDdoGGToe3+tRdCtwgeTwZvps3+rmaFiWETlmciTN5ysJVv EvO9qty97KgMW26h0UBVhUPBmo240dmuvZGOm5yX7zYzgfAM43LzEk96RP0eBt0wr39cxrM+/z3 lxpsISJl8lbjLgPRXLem+GGjfXi3VF21yPOpJRAtZ8on9PZkl0v8rV1sRJJFUe44gmoTWmEIDoR lYD1SRgHh9XhuKuu2oZdaQjyJelT0H4xCThpyiFAU0U/sJqDsOg/6nS/08JdMeSruo4Jg4VzQ0B q0KN+E0ttP7Saq26a4SkFYmhNn2ZaYEx3iyl6ciB7mPKyI3SlJFF5QFuOjWP44knxdz4wFdjEhl YhkxlDfM3jqemvviRSwdOeWrn2A== X-Received: by 2002:a05:620a:4688:b0:8d7:f950:ea4d with SMTP id af79cd13be357-8ddcce2b2camr1911697285a.4.1776094779468; Mon, 13 Apr 2026 08:39:39 -0700 (PDT) X-Received: by 2002:a05:620a:4688:b0:8d7:f950:ea4d with SMTP id af79cd13be357-8ddcce2b2camr1911690585a.4.1776094778787; Mon, 13 Apr 2026 08:39:38 -0700 (PDT) Received: from [192.168.2.110] ([69.159.169.238]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8ddb646d715sm856838885a.15.2026.04.13.08.39.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Apr 2026 08:39:38 -0700 (PDT) Message-ID: <87f89b9c-002e-4210-adbf-f24201797ccc@redhat.com> Date: Mon, 13 Apr 2026 11:39:27 -0400 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 v3 09/10] mm: thp: always enable mTHP support To: Baolin Wang , 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: <6dea717fe8c86003e7da33c9a7623b834649d5ee.1775679721.git.luizcap@redhat.com> <5e653a9b-9265-4bfd-89ce-f0fbe0df2ae6@linux.alibaba.com> Content-Language: en-US, en-CA From: Luiz Capitulino In-Reply-To: <5e653a9b-9265-4bfd-89ce-f0fbe0df2ae6@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-04-11 03:22, Baolin Wang wrote: > > > On 4/9/26 4:23 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 | 13 ++++++++----- >> mm/shmem.c | 4 +++- >> 2 files changed, 11 insertions(+), 6 deletions(-) >> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 86e489c0a150..6de3d8ebc35c 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -118,6 +118,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; >> @@ -125,7 +128,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. */ >> @@ -787,7 +790,7 @@ static int __init hugepage_init_sysfs(struct kobject **hugepage_kobj) >> * disable all other sizes. powerpc's PMD_ORDER isn't a compile-time >> * constant so we have to do this here. >> */ >> - if (!anon_orders_configured) >> + if (!anon_orders_configured && pgtable_has_pmd_leaves()) >> huge_anon_orders_inherit = BIT(PMD_ORDER); >> *hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj); >> @@ -809,6 +812,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)); >> + >> order = highest_order(orders); >> while (orders) { >> thpsize = thpsize_create(order, *hugepage_kobj); >> @@ -908,9 +914,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 613393eae5a9..b49a30475cb0 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -1839,7 +1839,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, >> @@ -1947,6 +1947,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)); > Sorry, I still don't like the changes here, because shmem_allowable_huge_orders() is meant to determine which large orders are allowed. Something like below (untested): Sure, I can do something like this. > > @@ -1834,6 +1834,7 @@ unsigned long shmem_allowable_huge_orders(struct inode *inode, > struct vm_area_struct *vma, pgoff_t index, > loff_t write_end, bool shmem_huge_force) > { > + unsigned int filter_orders = pgtable_has_pmd_leaves() ? (BIT(PMD_ORDER) | BIT(PUD_ORDER)) : 0; > unsigned long mask = READ_ONCE(huge_shmem_orders_always); > unsigned long within_size_orders = READ_ONCE(huge_shmem_orders_within_size); > vm_flags_t vm_flags = vma ? vma->vm_flags : 0; > @@ -1846,7 +1847,7 @@ unsigned long shmem_allowable_huge_orders(struct inode *inode, > shmem_huge_force, vma, vm_flags); > /* Tmpfs huge pages allocation */ > if (!vma || !vma_is_anon_shmem(vma)) > - return global_orders; > + return global_orders & ~filter_orders; > > /* > * Following the 'deny' semantics of the top level, force the huge > @@ -1871,6 +1872,7 @@ unsigned long shmem_allowable_huge_orders(struct inode *inode, > if (global_orders > 0) > mask |= READ_ONCE(huge_shmem_orders_inherit); > > + mask &= ~filter_orders; > return THP_ORDERS_ALL_FILE_DEFAULT & mask; > } > > > Additionally, we also need a pgtable_has_pmd_leaves() check before setting huge_shmem_orders_inherit as well. > > @@ -5428,7 +5430,7 @@ void __init shmem_init(void) > * Default to setting PMD-sized THP to inherit the global setting and > * disable all other multi-size THPs. > */ > - if (!shmem_orders_configured) > + if (!shmem_orders_configured && pgtable_has_pmd_leaves()) > huge_shmem_orders_inherit = BIT(HPAGE_PMD_ORDER); > #endif > return; >