From patchwork Tue Nov 12 07:45:47 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 13871825 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 50DC9D41D65 for ; Tue, 12 Nov 2024 07:46:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7389F6B00D5; Tue, 12 Nov 2024 02:46:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E92D6B00DC; Tue, 12 Nov 2024 02:46:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B0266B00E1; Tue, 12 Nov 2024 02:46:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3DF8B6B00D5 for ; Tue, 12 Nov 2024 02:46:02 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DF4D1AD8A4 for ; Tue, 12 Nov 2024 07:46:01 +0000 (UTC) X-FDA: 82776657600.27.5D76324 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf13.hostedemail.com (Postfix) with ESMTP id 849D42000D for ; Tue, 12 Nov 2024 07:45:16 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="LOzHq/2O"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731397473; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=ZYC5bpSYWv5P3qsOnKs0Y3rLvkMWTCSi3IfFbvJXsAg=; b=SgRtCmnn7+t1ogEJLcWXNRq2TOLTTSGebrBizCkl2Mt1ZeJYQdmNY820YuRhehcbNFVYUI SzRV5r0nxyBrQuafwkIojTGPWvcvcAytyzR3x1fs8tj6DpBoHru2vSZxP2kB67hhJDyuvI szKTtQpO9Zqb/+HXuuNgMhJeem/lERE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="LOzHq/2O"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731397473; a=rsa-sha256; cv=none; b=Mh8VMxcVYAvFy9PsMcv4dsJxe1JwZV3kIcEacPKIK7RqedmXXC+GxEczUcoH/67PhfMHtS Py2g1y3BCNAlGDW7b6dY2UttU+ze79TD0hhvb7ABWH6yJZqfv86pzNagGvBeParnqfQ8pZ A/7TBSU/Z2dVbqW9WLnmTvNRqA8VuOE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1731397556; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=ZYC5bpSYWv5P3qsOnKs0Y3rLvkMWTCSi3IfFbvJXsAg=; b=LOzHq/2OG+X8tAF0ItcO5D93f6PNh4gUSQsHNrF+CTVvzoHjXVjzigpJ2Drq9yhGwFpH60vutJ44LWDSUPlogLDQKFWFG01RmXuurH/L5oY3wHW+PronidhFYhsCic4MaoTcH+p9PnKIYOluUgPddEJEdomN60u89iPvjUaiMvY= Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WJGDWmE_1731397554 cluster:ay36) by smtp.aliyun-inc.com; Tue, 12 Nov 2024 15:45:54 +0800 From: Baolin Wang To: akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, da.gomez@samsung.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/5] Support large folios for tmpfs Date: Tue, 12 Nov 2024 15:45:47 +0800 Message-Id: X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 849D42000D X-Stat-Signature: kzf3doo9km4tfb1ydbzpos3tisu5w36b X-HE-Tag: 1731397516-859872 X-HE-Meta: U2FsdGVkX1+/2FZhd+7Wx4vVGBl2VjdpgLEmHgDCBZFLxVWROKK36ErMUJu/lc2CP/WdWZYId/owqO0VsucdQRnDJ/XGteuAPTOFSXSu5a7BOJMfEL9S1qJXn+oviWgi2sLzwYEqnpmS62eaoilkly6ysFjGbizbKHyShfkt51QkJL5NLHEGiUjYiHBv5lnsztYjEb7P8EX3hPZsgl7UhZ/jMfCbTieu+8HZBfPl1mWSYVy2nvnWjh4PNXNbdf5bsG19iZSOqXxC3u9AgNUx+JleQXpNUOpd5qvlEGpe+TJ5XBBtSw3xmQKL5soug5nu9+6LB7+HmCTy+8DWBGDGtaoDAQVwz2luWYbw0u/SXzcJz+PrefWiDGZeRnhEAuIu7Ih9kA0evyQnF9jf0oqHYTTMuf+hJIFUt9eAU5ouCLeMMJJ6NtPflXBEzRz/mYD0NHKADGgZVdg/9mq/RqZPW2lV5V9vS7vNUuo+ZNYP6PlMXk/g9VgLaI4IYx9EmQrxM5d0PldrWgJ0dSJsxETw44GKeUKJBjzWj8fg6HWX7RSo4k0uTV6iEJhc9hMIbKKuxWot2r5SZLg2lhBNSJYwUpDK6rL//E47GMX5hmhFahpXOoCsfeyqxZywD8hvY1NVs7DTcitXaA7CeWCQkU1gKBMmIWgzPyIWV7hx6H6w3edmBfhzDYlksjNyEmc3k3roeAkigiIXMdYZgKQbH+EPqUgAjXJD0XNds8lod7SrXZeh2Mki0w7M0aGQNmsxbMb3gjDL89QezQmubwo3Bid1PuuleH0g6/xw58GPg/wvBnyBCZMF38kWT2txhsOcB5lf5FVkK3xs3bsfGNWgwJV6mvb86m6qkemCKH2ZTmLPCYL0DFOmSELSVvlTxuUb2iZ4y+xmprxkMYkBgJh0NpDpROmUbtS13SW4Zu7lr2fRZY1ejau3iTifkBqAe2BWJqq/fMiYhvE9QNo5PgH0ycn xVSXN3iT g13xmdPGX+8GhC463/UeiE2wrz2macK2Mv0/FO+1JcJbnDBdpcb3RiuItAjuOIbNtPhQIkmHpvRjLRhk005M1Owl2D5ra3173osLBuadv1weMylpL1xHPOfB16eM64SAWFmWsXrLDiXSYRfN/sPHomKxMRMgIVd8bZs0sA38IzlUXuRRI5Yh7lIX27arhaYVzZAAuhdGTngIOgeE= 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: Traditionally, tmpfs only supported PMD-sized huge folios. However nowadays with other file systems supporting any sized large folios, and extending anonymous to support mTHP, we should not restrict tmpfs to allocating only PMD-sized huge folios, making it more special. Instead, we should allow tmpfs can allocate any sized large folios. Considering that tmpfs already has the 'huge=' option to control the huge folios allocation, we can extend the 'huge=' option to allow any sized huge folios. The semantics of the 'huge=' mount option are: huge=never: no any sized huge folios huge=always: any sized huge folios huge=within_size: like 'always' but respect the i_size huge=advise: like 'always' if requested with fadvise()/madvise() Note: for tmpfs mmap() faults, due to the lack of a write size hint, still allocate the PMD-sized huge folios if huge=always/within_size/advise is set. Moreover, the 'deny' and 'force' testing options controlled by '/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same semantics. The 'deny' can disable any sized large folios for tmpfs, while the 'force' can enable PMD sized large folios for tmpfs. Any comments and suggestions are appreciated. Thanks. Changes from v1: - Add reviewed tag from Barry and David. Thanks. - Fix building warnings reported by kernel test robot. - Add a new patch to control the default huge policy for tmpfs. Changes from RFC v3: - Drop the huge=write_size option. - Allow any sized huge folios for 'hgue' option. - Update the documentation, per David. Changes from RFC v2: - Drop mTHP interfaces to control huge page allocation, per Matthew. - Add a new helper to calculate the order, suggested by Matthew. - Add a new huge=write_size option to allocate large folios based on the write size. - Add a new patch to update the documentation. Changes from RFC v1: - Drop patch 1. - Use 'write_end' to calculate the length in shmem_allowable_huge_orders(). - Update shmem_mapping_size_order() per Daniel. Baolin Wang (4): mm: factor out the order calculation into a new helper mm: shmem: change shmem_huge_global_enabled() to return huge order bitmap mm: shmem: add large folio support for tmpfs mm: shmem: add a kernel command line to change the default huge policy for tmpfs David Hildenbrand (1): docs: tmpfs: update the huge folios policy for tmpfs and shmem .../admin-guide/kernel-parameters.txt | 7 + Documentation/admin-guide/mm/transhuge.rst | 64 ++++++-- include/linux/pagemap.h | 16 +- mm/shmem.c | 148 ++++++++++++++---- 4 files changed, 183 insertions(+), 52 deletions(-)