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.133.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 3AF1912CD8B for ; Thu, 9 Apr 2026 20:07:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775765231; cv=none; b=GNaJqmIpM19nlNSPceRR5hZ2A0zjiHyxubnGGmvFSi087I5XLMm1GFKvp7ksCTALdeVB1KaFrjagP3NEKxdaNFsj1gFYuI/azHt/ispRL1YeEKoxXeP++XaUItp+iZTOY6k8+PWg1x8XkqtF3pbs3IDUD9eZAMTFww3DkT1qY/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775765231; c=relaxed/simple; bh=0vt+j1hoNkx95rWFrgXSAaccCZOCdnjgpUq5gqT4tWg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ACo3dGDT849qiJzbunCDh4mdk4pNXkQvmtcesF2DtwO4kvF4qcRpHZeG3NpS5un0WhfkfV6BgG+El/x39T3n/7FZgJ75HZTmmCRs6rwlfqP+za7yB/Cd/LRSaR1IpJEoLlk4HMDcKWujFBFz4vl7FUknyumK7zhGrberiG0pbSM= 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=Vc4uTJpK; arc=none smtp.client-ip=170.10.133.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="Vc4uTJpK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775765229; 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=/noGlVUyCBU9SCMkKfV/73/nLArO8jWoLAogqLw1xDk=; b=Vc4uTJpKZVdJkBcAVpA5Lpcr7N+GQ5vLCURuuttvLuR2y2NsL2Up2veVmgahwsWaZpfkUX rSVPSg57AvVw/U3uTUZiphiVCef9t20IBc3v2KrJ3jgRPya7GvaRqts2efoznTNWn9Sqme L8lOQxuyf0SD9oEst8VqdEPGicISY+o= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-554-pKCyw6tuNFaCzvpbJV-V9A-1; Thu, 09 Apr 2026 16:07:08 -0400 X-MC-Unique: pKCyw6tuNFaCzvpbJV-V9A-1 X-Mimecast-MFC-AGG-ID: pKCyw6tuNFaCzvpbJV-V9A_1775765227 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-8a14905811cso36064236d6.2 for ; Thu, 09 Apr 2026 13:07:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775765227; x=1776370027; 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=/noGlVUyCBU9SCMkKfV/73/nLArO8jWoLAogqLw1xDk=; b=evAMMszci9EqH/M5OoiOx5GY6MY0sBLWu6SLCFT7bCUDM05nT7YyOEO1OunHBPwwtx 0fd2B5v8shs48jBioHiOB/s6N9TGPqaQ0bmMkojAMWrpGHG2HOHFIhu0jVHEhXgcLlCu a9kEMYxp8DudjwJhQPYGqvjbqAujm7si5R+2qfLOVo54JrNHBEZ0o97zycaDEK01A7E/ FebRWg02/x0+GCqYxQHRhJeNoI0+N4r6tc7Lgh06g/SXCcZNrKy5VxaUe2LTHg+CNONN PH4gvozkWSFQg1dkVKeF6TttXq66P/RyJUziDcte2efN5eqvSGzZuw1beMkuWriYsbRU WI9w== X-Gm-Message-State: AOJu0YyOtMlHMiH20DaA546FG0Sc426H2laUiX7UWUuPlc8w0V34Que/ hCTvNItxY18RripByFXm1URL5QTO22iJmplZA5PorKwWCepORxq63f0MWAc5DQNj9SDXF0uMmPR cTeo1OM1msJiJGDPIx5wD3QGpgg010trLweX3OE93RlIQdc+hNkSJF2Zr1VeGIMNFaSxf9v/0Wg == X-Gm-Gg: AeBDieuMajntYUbmMizW/+tQnRCFxiA9bMP99jLkpAYdp6e24KnAWJ03JMGXQc7FQLP Yk0pZqLZJlxKurnHP2hdLdv0u1akw2jZij9VZOxAsEyeKxdhN4TNeW+7Z15BsZQFl69vJny1z/i i2Rk5JyEibU4aJ4WaSr704GIU8waDF1L3nyCkE485NSPSwp8nKTSU/2Q9idGfE25yeaVIKWPdZ8 JcBA1iDZF8ZDYyJzGrpP2gr7AUUHPkDQRxHP3fkT0nCjnxisA3S8l9AszxFakaNOxPQJijZYZoK tN0eSbUFZJcga3k6PtqWXwxYBZ1Tu+M63uGXlgz6JM3z+IaKixERNgt/vTevyBBdSX+hZxye48G HyPZsEmyyOIfOT9qPkXcCHmQUnE8xOTpNpU8bFEYr4qvEXdgNYoVl/cyDai+1mVGDOxmlGxopKo N7x3vu8QoYbV1QzSE= X-Received: by 2002:a05:6214:8093:b0:8a5:104b:e385 with SMTP id 6a1803df08f44-8ac8629b4c2mr2842386d6.35.1775765227228; Thu, 09 Apr 2026 13:07:07 -0700 (PDT) X-Received: by 2002:a05:6214:8093:b0:8a5:104b:e385 with SMTP id 6a1803df08f44-8ac8629b4c2mr2841986d6.35.1775765226718; Thu, 09 Apr 2026 13:07:06 -0700 (PDT) Received: from [192.168.2.110] (bras-base-aylmpq0104w-grc-53-69-159-169-238.dsl.bell.ca. [69.159.169.238]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ac84cffe76sm5587716d6.47.2026.04.09.13.07.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2026 13:07:06 -0700 (PDT) Message-ID: <7830cda5-b3df-4da1-805b-278d5af6b2b1@redhat.com> Date: Thu, 9 Apr 2026 16:07:00 -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: Zi Yan Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, david@kernel.org, baolin.wang@linux.alibaba.com, ryan.roberts@arm.com, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com References: <6dea717fe8c86003e7da33c9a7623b834649d5ee.1775679721.git.luizcap@redhat.com> <772C4431-FA93-4477-B1CE-3BE5EA97FD0B@nvidia.com> Content-Language: en-US, en-CA From: Luiz Capitulino In-Reply-To: <772C4431-FA93-4477-B1CE-3BE5EA97FD0B@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-04-09 11:55, Zi Yan wrote: > On 8 Apr 2026, at 16:23, 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)); > > Why is BIT(PUD_ORDER) also removed? I thought PMD THP support and PUD THP support > are separate. Here the code implies PUD THP relies on PMD THP. Is that the case? This was a suggestion from David to an earlier version: https://lore.kernel.org/linux-mm/dac20466-adac-4e47-8f50-87f4774fd57b@kernel.org/ My understanding was that if an arch doesn't support PMD pages then it probably doesn't support PUD pages either. >> + >> 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)); >> + > > Ditto. > >> 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 >> */ > The code after is: > > MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER > MAX_PAGE_ORDER); > > Should this check be removed or only performed when pgtable_has_pmd_leaves()? > > I do not know if there is a possible Kconfig that lowers MAX_PAGE_ORDER > below PMD_ORDER and enables THP. After this patchset, that might be valid > if people do not want to use mTHP but not PMD THP. I need to look into this more carefully to be able to answer this, I'll get back to you. >> 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)); > > Same question as the first one. > >> >> if (orders > 0) { >> suitable_orders = shmem_suitable_orders(inode, vmf, >> -- >> 2.53.0 > > > Best Regards, > Yan, Zi >