From patchwork Fri Nov 8 04:12:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 13867519 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 C9773D5E124 for ; Fri, 8 Nov 2024 04:13:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A2306B00B0; Thu, 7 Nov 2024 23:13:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3030B6B00B7; Thu, 7 Nov 2024 23:13:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03EF16B00B4; Thu, 7 Nov 2024 23:13:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D5C1E6B00B0 for ; Thu, 7 Nov 2024 23:13:30 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3C8921A01C3 for ; Fri, 8 Nov 2024 04:13:30 +0000 (UTC) X-FDA: 82761607446.10.E0D4D7D Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf13.hostedemail.com (Postfix) with ESMTP id DD70E20009 for ; Fri, 8 Nov 2024 04:12:49 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=MtYIpng6; 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.131 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=1731039123; 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=EkuPdbEJs10NbPrHB3oDX2u1XBW62xxYxS7y55GIsZw=; b=TpifSCsqKe5eCmQ5NROSQSclE2V+5qPqAa2BbqGMjpI+/GL4e2SktPzSjBwB+KUbwKKpag xSpY/9Ah7ackTXRo+jfsp/Q4IhVFWQLqn7we26RZ2q2sksljBEd+0j54HKALUxfgTOaPUW fU+rrp335Ol9tMYPG4KrryfoQ7o09X8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=MtYIpng6; 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.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731039123; a=rsa-sha256; cv=none; b=qgBLx/RcYYyXvj+v72yMu17CeJPzL1zHQp6L5rcUsbbJxvXhbI4Jo0ZgFzfEpMAjEL/FuQ 2MEEdcja0anGqxa6lruZ9GDVhFzV7KFYX4sTPEX9c9tDF5rhDeeu/q5VPe0xhn8YdMLQIQ S9eNqe0MzTxNT9Q0nrEubW0FtW7VAqc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1731039204; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=EkuPdbEJs10NbPrHB3oDX2u1XBW62xxYxS7y55GIsZw=; b=MtYIpng6iPQjJGg7/FFCN657t0SdNbf9ud/uGev07abrMzuhKcdG0svH88LJDK8a9QqQi15jP8rYwxL2KMdBCohQT7Q3OvbodVzK4bv02eM74Lb2wR/7ic3r8fBjze0jSGvZJYB9FYOi5VvP5UJkIE0stF8XOcQKbEy1MkUvHg0= Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WIxXGhC_1731039201 cluster:ay36) by smtp.aliyun-inc.com; Fri, 08 Nov 2024 12:13:22 +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 0/4] Support large folios for tmpfs Date: Fri, 8 Nov 2024 12:12:54 +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: DD70E20009 X-Stat-Signature: n5wef1ghzwpoc3eowjijjqqaqu949new X-HE-Tag: 1731039169-883892 X-HE-Meta: U2FsdGVkX1/0Vc06rP8tV9tZCeFZZ0DhyX0l6oxUMUZmyaH3b3RLn7J5m4rrzAt+ux7sxWKc78VcYlCV68869Cv5ev4kIcbIwV+rOpdZwKil7VYZhen3iwJopSPoeFQa2wSruZhZJ+bJRkcG51w00pbZT/B5mm5OtPVZG7is1TtCgcTIqpe1omAXs0uHcPL41/P88tvkMJO7VCdQKP9rdEGDhD97OQ0tdbQZEC3RN9LE+UpcnWHgC+tBDeZTJ5V1WGe2fzZeCkq5iuD8aMLSkRg7PslVxuYxLX6e9zcCmyPBBy4rdKtzWYOVuWc7wffpPJkta6xL7DGK0lOwvND7AQtYAc+En3PuF+cyg9KBO69jxz6bP9vZqQD3tn4JrlzlzboQJrG08sTbMNEm8GSQPuKgD2lZv/RM5hOsSiw1DYeF92UKD8zxJpBaBkbM34J2vjxfcZjOuoVJLPq/Z5euB7Y9tMtF9klMOT1hMt5I+NaJlc6oOYbTcI7VldM0BW1GLrpXf2EyOYLSEEJ1KtC/wgXr9jbue0UHXAV9Ep4ZIjRjVN0e18kqEUOB5NqNOGGm/+lL3P5rsetu6L/MhBblgxnJj+4c700eZnreMGz4mJdtbRjZg1y9Qi3mvP7q57cyI1cpKtehyRTNvwTmn8mhTvV6HcROCGXZbMpVJScArKkyie7mUmNp4J6YgQH0DztsmFEEJr6fngUMz6IK5nESo9LsUyNoTAAZYioEVv8afaPc3vOw66TortxI37tqj2CZXR1M6c34jEx6497meHTse32IYRAGs/p5GaOAOhLlzv0R98DCXS7ZzDFYV3qytEmZuimSbb9wI3egaoSc9Yro7qnvh1BG6LomJywbWuc4FlYVZVb5KQuaRG27rcBNljp7cdQ70hajKIHncgd1n4KzhEZTqU1vRMvt2nImWwhjEJcHLjzMcrg/WkqeUA8ynJJ0FD9YyKgypvy4BHx60/s sbWF9fpN d68s6qTMGCfMnIjU7ttQbvObpYH4eXD3I1ZrHqkH6OBnQX9nPBRH8a1wI1KU1CGeRPOjjJMMDfFjfQRjp5KYf/RoIzoe1tO+C7WUjuOZAJ3b6N5bK5KHIqLK1/GaCK0bKjOHNLARTxNNjmy56YrUfPAchWdksN6SbHFofegRNdK1gYeqLn5NXKwfJOLAwA4K3iIkyPNTUTq+fldc= 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. Hi David, I did not add a new Kconfig option to control the default behavior of 'huge=' in the current version. I have not changed the default behavior at this time, and let's see if there is a need for this. 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 (3): 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 David Hildenbrand (1): docs: tmpfs: update the huge folios policy for tmpfs and shmem Documentation/admin-guide/mm/transhuge.rst | 52 ++++++--- include/linux/pagemap.h | 16 ++- mm/shmem.c | 128 ++++++++++++++++----- 3 files changed, 146 insertions(+), 50 deletions(-)