From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1F3AC3DA7F for ; Sun, 4 Aug 2024 18:46:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E36A36B007B; Sun, 4 Aug 2024 14:46:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE69B6B0082; Sun, 4 Aug 2024 14:46:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C38E86B0085; Sun, 4 Aug 2024 14:46:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A70D06B007B for ; Sun, 4 Aug 2024 14:46:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 59B2DA1A21 for ; Sun, 4 Aug 2024 18:46:51 +0000 (UTC) X-FDA: 82415444622.26.75AF4EA Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by imf17.hostedemail.com (Postfix) with ESMTP id F32F940013 for ; Sun, 4 Aug 2024 18:46:46 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=rdJVq9NQ; spf=pass (imf17.hostedemail.com: domain of da.gomez@samsung.com designates 210.118.77.12 as permitted sender) smtp.mailfrom=da.gomez@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722797147; h=from:from:sender: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:dkim-signature; bh=CnZjGZTaSlKAOieUX7VlTJu7A5nt3wz6fCf1ekZdmfU=; b=o2zpQ+9cVzG/0hVI+rGDbY82Puefuau4Z7QJN+p47kbHBmRx2UcpIxv4vf7XLyGPxxhYwn nLJYF/m8MmHE+9j82jAUpx7DTz0bTZkYIbSmhlTsSHkBF/Tbn2odFEprL6kaSpyVbNtU5Z yNReqoWTsI5reVyUbdjufLATGT1F96U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722797147; a=rsa-sha256; cv=none; b=MP6nojggaejFPyJvbmpYYbeZLautaHb/WYuin8YrpPI3EX7nXIuV05eQVIcPXbFK9c4F4F 8a71wu0uPtiQXrCuhiOvhodHT0qNZgaxXrdmlOMpRDGOaFVKCRB0D9oKJAa3kNn/8jDjxJ LqQmDJNwYhTLxlwoqu5hhmtswoZIq8s= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=rdJVq9NQ; spf=pass (imf17.hostedemail.com: domain of da.gomez@samsung.com designates 210.118.77.12 as permitted sender) smtp.mailfrom=da.gomez@samsung.com; dmarc=pass (policy=none) header.from=samsung.com Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20240804184644euoutp02db5a7647792d184e15f2dfd82016b0a9~omu38GJMt2123621236euoutp022 for ; Sun, 4 Aug 2024 18:46:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20240804184644euoutp02db5a7647792d184e15f2dfd82016b0a9~omu38GJMt2123621236euoutp022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1722797204; bh=CnZjGZTaSlKAOieUX7VlTJu7A5nt3wz6fCf1ekZdmfU=; h=From:To:CC:Subject:Date:In-Reply-To:References:From; b=rdJVq9NQXjMJVD048re41vvVWXB96FLwbXYiDNbDyIXTkbx9FXhtU33evqLUMIrEo 8LpU2wSEpR2KKjeUTcAfBvSArmhLkwoKv3Ac0CXJPLIQDvY6HSIwXD2GCJjm1D8pLT ggicRnnb8OewEyvpx3QALZna4oth9tpMScfwgf0s= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20240804184643eucas1p216baf4fd99304c6d53f6274c2790ac79~omu3Zdrhb2228522285eucas1p2S; Sun, 4 Aug 2024 18:46:43 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id B6.9B.09620.39CCFA66; Sun, 4 Aug 2024 19:46:43 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20240804184643eucas1p233add8b76d020da3ca97f0dc2665a556~omu25NCP-1682016820eucas1p2-; Sun, 4 Aug 2024 18:46:43 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20240804184643eusmtrp12a5c0f5f31b93bfc39f1b9d530256668~omu24gRUV2636326363eusmtrp1s; Sun, 4 Aug 2024 18:46:43 +0000 (GMT) X-AuditID: cbfec7f5-d1bff70000002594-da-66afcc9330ae Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 02.71.08810.39CCFA66; Sun, 4 Aug 2024 19:46:43 +0100 (BST) Received: from CAMSVWEXC02.scsc.local (unknown [106.1.227.72]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20240804184642eusmtip261af6638d5c6f1e14029482bee911de1~omu2oCsLN1161011610eusmtip2I; Sun, 4 Aug 2024 18:46:42 +0000 (GMT) Received: from CAMSVWEXC02.scsc.local (2002:6a01:e348::6a01:e348) by CAMSVWEXC02.scsc.local (2002:6a01:e348::6a01:e348) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 4 Aug 2024 19:46:42 +0100 Received: from CAMSVWEXC02.scsc.local ([::1]) by CAMSVWEXC02.scsc.local ([fe80::3c08:6c51:fa0a:6384%13]) with mapi id 15.00.1497.012; Sun, 4 Aug 2024 19:46:42 +0100 From: Daniel Gomez To: Baolin Wang CC: "akpm@linux-foundation.org" , "hughd@google.com" , "willy@infradead.org" , "david@redhat.com" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "ryan.roberts@arm.com" , "ziy@nvidia.com" , "ioworker0@gmail.com" , Pankaj Raghav , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 2/3] mm: shmem: add large folio support to the write and fallocate paths Thread-Topic: [RFC PATCH 2/3] mm: shmem: add large folio support to the write and fallocate paths Thread-Index: AQHa3ZffsQ55Yux8QEaDgkDF/II6u7IXcVUA Date: Sun, 4 Aug 2024 18:46:41 +0000 Message-ID: In-Reply-To: <05a31373ee1aa40a6a85d4897324a400686e2fb1.1721720891.git.baolin.wang@linux.alibaba.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [106.210.248.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <93390B0AC88DFF4D9A88DBE98F0A32A6@scsc.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsWy7djP87qTz6xPM5i9ScPi810hiznr17BZ /N97jNHi6/pfzBZPP/WxWCz6bWxxedccNot7a/6zWvTsnspo8fsHkDv76D12B26PNfPWMHrs nHWX3WPBplKPzSu0PDZ9msTucWLGbxaPnQ8tPXqb37F5vN93lc3j8ya5AK4oLpuU1JzMstQi fbsEroyGh13MBc8tKuZdvM3WwLhTp4uRk0NCwERiw8ndrF2MXBxCAisYJV7dmMQO4XxhlNi9 5ggThPOZUWL1x8uMMC1TXlxlg0gsZ5T4cesGC1xVz8057CBVQgKnGSX69ovBDW5ecBIswSag KbHv5CYgm4NDREBfoneuL0gNs8AfZolTm7+xgsSFBZIk7v9OAykXEUiWaP/axgZhG0nsvLwD zGYRUJFYufklI0g5r4CvxPKb/CBhToEUidcHrjGB2IwCshKPVv4C28osIC5x68l8JogHBCUW zd7DDGGLSfzb9ZANwtaROHv9CdSTBhJbl+5jgbAVJZa+uMsKMUdHYsHuT2wQtqXEhIWPoeLa EssWvgabyQs0/+TMJ+AwkRCYyiVx8Hk31FAXiV+dd9ghbGGJV8e3sE9g1JmF5L5ZSHbMQrJj FpIds5DsWMDIuopRPLW0ODc9tdg4L7Vcrzgxt7g0L10vOT93EyMw4Z3+d/zrDsYVrz7qHWJk 4mA8xCjBwawkwvts79o0Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryqKfKpQgLpiSWp2ampBalF MFkmDk6pBqaue7o2+be22G6OmBd6inOBA9uXilPdX9/K8z4/fXBjLeNXRa8fO04fNjgc0Kl5 0LxV3PzIkemTkviUU9+uWzKh3V3sj/LXM1EWSwuXXp2/8VvAXO73kaonWytZPj4q5dx/Ovje mYV/FjUKvIx+xqaW/KGpQy1qIme8aF3lrfi8xQflGY7Yvtg9ZdHdxs7fM6QPnlpzr3HiiamX EmWCH/tHygjz/jPhtHCJEJ1mu/vG/t4DnU+n/F1YmSAZtunN5vOLEvIjnk6pneG3ha83gXfB r1dtZ6VCO/awbPbo+r3MMyZjpevMfvny5bk/a2LWlB0oLqqsuqvdGHKD4aXN/8/NlVs9LSe+ ttk3Sy1qy5ZUJZbijERDLeai4kQAr9KQ0OcDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLKsWRmVeSWpSXmKPExsVy+t/xe7qTz6xPM3i3nc3i810hiznr17BZ /N97jNHi6/pfzBZPP/WxWCz6bWxxedccNot7a/6zWvTsnspo8fsHkDv76D12B26PNfPWMHrs nHWX3WPBplKPzSu0PDZ9msTucWLGbxaPnQ8tPXqb37F5vN93lc3j8ya5AK4oPZui/NKSVIWM /OISW6VoQwsjPUNLCz0jE0s9Q2PzWCsjUyV9O5uU1JzMstQifbsEvYyGh13MBc8tKuZdvM3W wLhTp4uRk0NCwERiyourbF2MXBxCAksZJVZPv84CkZCR2PjlKiuELSzx51oXVNFHRokt2++z QzinGSWuTz0IlVnBKLH+9nxmkBY2AU2JfSc3AVVxcIgI6Ev0zvUFqWEW+MMscWrzN1aQuLBA ksT932kg5SICyRJXH+xhh7CNJHZe3sEGYrMIqEis3PySEaScV8BXYvlNfohV7xglvk/+xwhS wymQIvH6wDUmEJtRQFbi0cpfYHOYBcQlbj2ZzwTxgYDEkj3nmSFsUYmXj/9BfaYjcfb6E0YI 20Bi69J9UN8rSix9cZcVYo6OxILdn9ggbEuJCQsfQ8W1JZYtfA02k1dAUOLkzCcsExhlZiFZ PQtJ+ywk7bOQtM9C0r6AkXUVo0hqaXFuem6xoV5xYm5xaV66XnJ+7iZGYDrbduzn5h2M8159 1DvEyMTBeIhRgoNZSYT32d61aUK8KYmVValF+fFFpTmpxYcYTYFhN5FZSjQ5H5hQ80riDc0M TA1NzCwNTC3NjJXEeT0LOhKFBNITS1KzU1MLUotg+pg4OKUamORU9rxN/7LXLe21zeSggBuz lrr+vsr+5sG2idem22zW3CnNeFpt4e60hnWXAi50r36Sz1vv+zDjZ2DfJMYY/m2Xb833fyXI 8czVJS/n+OTIOz6ugvnL2yfZlfwVcWbI1+KNDcy3WxzMtiaa8eqb0Hli7yt/Ps57z3ntpGVT s8KuhAkXur+9ebxATt5GpM/rcE2532vV00xRNdLrVIO2Xf+tvX35RZvlZisvdgvUzjEt3hCz Z7nodJt9Xg/mcJlf25B8juHncd96M7eXM6ewfi7qbGeSi9I1Ej6od2dnyHbGPfNmz9IxSPmS p/pgmeGG3E2mV9Vunq35MiXR65G+E3NSlnNSxLmoxnI/7ljmO0osxRmJhlrMRcWJACGBr6bw AwAA X-CMS-MailID: 20240804184643eucas1p233add8b76d020da3ca97f0dc2665a556 X-Msg-Generator: CA X-RootMTR: 20240724070423eucas1p1c2a306d0b44f73476b83ede2bd05e57a X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20240724070423eucas1p1c2a306d0b44f73476b83ede2bd05e57a References: <05a31373ee1aa40a6a85d4897324a400686e2fb1.1721720891.git.baolin.wang@linux.alibaba.com> X-Stat-Signature: mwhez33jzg5coxdroc3oq1nd7yjyj4oe X-Rspamd-Queue-Id: F32F940013 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1722797206-117373 X-HE-Meta: U2FsdGVkX18bjzAWZyp5vvfFdMQTT06GGgq12iWLcKN1MObMPAjI798R41fVmvvNVHLCHGIBoWbVLo9p+m3k9U7fdmbkGVMMO2K8Iau+nEeK090qk2Ts8jW9L45IDSb4CEjFEcExItEEAXMi3PMjtEjoMm8A8rVDk7vQnsvcRSLgSCdIte0MMwae7lBmGMlvX9zaOj6gPRwe8REfmdx6tGj4ydEGhdu/KMs3BAX1TKy4NZoJyRzNIAjQw29CB3MMJV0bn4iPmPyyhZ5ILiW5nq1Hjix0lqhMug5PnINeEeiOE6v1jUDc4mGJvVvlPBXOF6J7U80NiLFwm1VWwS8AH7mYc3VWVruEf1DDoWcDblObM6HGNg50z1sXmosNs6S+tyi5Q5HBKfs761ygIKtBm0E35JD94SmOGIUorp/5siC3KXOebcNYgQZY+1GzSpqxDRONdvt3WJ5ajfxL+XSqc085GctrUYp/nqT71VXaEo7Q3NLC0PsC/TwGgwrsytvBt9zDEDI9DRKO7KlUjB/KIzoF+Xi0kpLrn3STVOdvqxOvtUfcLktIYVX9kX4E0etYawieODwPuppn2TU1ueIhLr9n6NMG3CBQhbJRW89QU4E8jIdQYdLb35GDf6qb7crRo6t4INZGuTd9EqsMDiQ1f2KbVd3mzE3Wo50Nk+/MFpcqbT8xdlFD8/cQqFz0OIpB6erdIzLzr+bxZsdW3Pu6XdLruzGX98u7nLEZwwVNWvu3Aw7YgA9HtF5kwy7L0aNuHaLkstI06hM0CiPj/QHRr2uhFNS5bj6Xk3+91PdHV9RqsHUuHZWvqTkRJ0GnjpodTXMTZKvfwBb4rqlgjGS3bC8LqRlEI+Xmi+NWMwr0VeJBGUw48iiHXJL8ivlD17f0w1dFQCSjZjrYh5nEqHip1GGR6EqGaxNKHzdf3Cmrc2W5j8Behly83tnrRPSCLYfmlneSVu8mpfA+HOCd+Up xKLd0/mG fb6ZKvBtKayFqXIxDGDhdPFmWN8jKceEZG2gGEyNQlsaZOBwwIErX9jdiwDOdnhOBE58zkPb34zmZFO3J348Nkacv1d4Of9m14uWSxDJbapOM1Dh/Xgb5PJJ95YUS/HZbAArjmfT0pofX5Z53DOpuAjlU6l7hwqDjMx05I5AOVLOegxVytmohDkkPFgFUIcPGMVhl X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jul 24, 2024 at 03:03:59PM GMT, Baolin Wang wrote: > From: Daniel Gomez >=20 > Add large folio support for shmem write and fallocate paths matching the > same high order preference mechanism used in the iomap buffered IO path > as used in __filemap_get_folio(). >=20 > Add shmem_mapping_size_order() to get a hint for the order of the folio > based on the file size which takes care of the mapping requirements. >=20 > Swap does not support high order folios for now, so make it order-0 in > case swap is enabled. >=20 > If the top level huge page (controlled by '/sys/kernel/mm/transparent_hug= epage/shmem_enabled') > is enabled, we just allow PMD sized THP to keep interface backward > compatibility. >=20 > Co-developed-by: Baolin Wang > Signed-off-by: Daniel Gomez > Signed-off-by: Baolin Wang > --- > include/linux/shmem_fs.h | 4 +-- > mm/huge_memory.c | 2 +- > mm/shmem.c | 57 ++++++++++++++++++++++++++++++++++++---- > 3 files changed, 55 insertions(+), 8 deletions(-) >=20 > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > index 34beaca2f853..fb0771218f1b 100644 > --- a/include/linux/shmem_fs.h > +++ b/include/linux/shmem_fs.h > @@ -113,11 +113,11 @@ int shmem_unuse(unsigned int type); > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > unsigned long shmem_allowable_huge_orders(struct inode *inode, > struct vm_area_struct *vma, pgoff_t index, > - bool shmem_huge_force); > + bool shmem_huge_force, size_t len); > #else > static inline unsigned long shmem_allowable_huge_orders(struct inode *in= ode, > struct vm_area_struct *vma, pgoff_t index, > - bool shmem_huge_force) > + bool shmem_huge_force, size_t len) > { > return 0; > } > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index e555fcdd19d4..a8fc3b9e4034 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -162,7 +162,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_ar= ea_struct *vma, > if (!in_pf && shmem_file(vma->vm_file)) > return shmem_allowable_huge_orders(file_inode(vma->vm_file), > vma, vma->vm_pgoff, > - !enforce_sysfs); > + !enforce_sysfs, PAGE_SIZE); > =20 > if (!vma_is_anonymous(vma)) { > /* > diff --git a/mm/shmem.c b/mm/shmem.c > index 92ed09527682..cc0c1b790267 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -1630,10 +1630,47 @@ static gfp_t limit_gfp_mask(gfp_t huge_gfp, gfp_t= limit_gfp) > return result; > } > =20 > +/** > + * shmem_mapping_size_order - Get maximum folio order for the given file= size. > + * @mapping: Target address_space. > + * @index: The page index. > + * @size: The suggested size of the folio to create. > + * > + * This returns a high order for folios (when supported) based on the fi= le size > + * which the mapping currently allows at the given index. The index is r= elevant > + * due to alignment considerations the mapping might have. The returned = order > + * may be less than the size passed. > + * > + * Like __filemap_get_folio order calculation. > + * > + * Return: The order. > + */ > +static inline unsigned int > +shmem_mapping_size_order(struct address_space *mapping, pgoff_t index, > + size_t size, struct shmem_sb_info *sbinfo) > +{ > + unsigned int order =3D ilog2(size); > + > + if ((order <=3D PAGE_SHIFT) || > + (!mapping_large_folio_support(mapping) || !sbinfo->noswap)) > + return 0; > + > + order -=3D PAGE_SHIFT; > + > + /* If we're not aligned, allocate a smaller folio */ > + if (index & ((1UL << order) - 1)) > + order =3D __ffs(index); > + > + order =3D min_t(size_t, order, MAX_PAGECACHE_ORDER); > + > + /* Order-1 not supported due to THP dependency */ > + return (order =3D=3D 1) ? 0 : order; > +} I have an updated version of shmem_mapping_size_order() that I didn't poste= d but uses get_order() instead as suggested in [1]: [1] https://lore.kernel.org/all/ZT7rd3CSr+VnKj7v@casper.infradead.org/ /** * shmem_mapping_size_order - Get maximum folio order for the given file si= ze. * @mapping: Target address_space. * @index: The page index. * @size: The suggested size of the folio to create. * * This returns a high order for folios (when supported) based on the file = size * which the mapping currently allows at the given index. The index is rele= vant * due to alignment considerations the mapping might have. The returned ord= er * may be less than the size passed. * * Like __filemap_get_folio order calculation. * * Return: The order. */ static inline unsigned int shmem_mapping_size_order(struct address_space *mapping, pgoff_t index, size_t size) * Return: The order. */ static inline unsigned int shmem_mapping_size_order(struct address_space *mapping, pgoff_t index, size_t size) { unsigned int order =3D get_order(max_t(size_t, size, PAGE_SIZE)); if (!mapping_large_folio_support(mapping)) return 0; /* If we're not aligned, allocate a smaller folio */ if (index & ((1UL << order) - 1)) order =3D __ffs(index); return min_t(size_t, order, MAX_PAGECACHE_ORDER); } order-1 is already supported by commit [2], so I've removed that condition = as well. [2] 8897277acfef7f70fdecc054073bea2542fc7a1b ("mm: support order-1 folios i= n the page cache"). > + > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > unsigned long shmem_allowable_huge_orders(struct inode *inode, > struct vm_area_struct *vma, pgoff_t index, > - bool shmem_huge_force) > + bool shmem_huge_force, size_t len) > { > unsigned long mask =3D READ_ONCE(huge_shmem_orders_always); > unsigned long within_size_orders =3D READ_ONCE(huge_shmem_orders_within= _size); > @@ -1659,10 +1696,20 @@ unsigned long shmem_allowable_huge_orders(struct = inode *inode, > vma, vm_flags); > if (!vma || !vma_is_anon_shmem(vma)) { > /* > - * For tmpfs, we now only support PMD sized THP if huge page > - * is enabled, otherwise fallback to order 0. > + * For tmpfs, if top level huge page is enabled, we just allow > + * PMD size THP to keep interface backward compatibility. > + */ > + if (global_huge) > + return BIT(HPAGE_PMD_ORDER); > + > + /* > + * Otherwise, get a highest order hint based on the size of > + * write and fallocate paths, then will try each allowable > + * huge orders. > */ > - return global_huge ? BIT(HPAGE_PMD_ORDER) : 0; > + order =3D shmem_mapping_size_order(inode->i_mapping, index, > + len, SHMEM_SB(inode->i_sb)); > + return BIT(order + 1) - 1; > } > =20 > /* > @@ -2174,7 +2221,7 @@ static int shmem_get_folio_gfp(struct inode *inode,= pgoff_t index, > } > =20 > /* Find hugepage orders that are allowed for anonymous shmem and tmpfs.= */ > - orders =3D shmem_allowable_huge_orders(inode, vma, index, false); > + orders =3D shmem_allowable_huge_orders(inode, vma, index, false, len); > if (orders > 0) { > gfp_t huge_gfp; > =20 > --=20 > 2.39.3 > =