From patchwork Wed Jul 24 07:03:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 13740623 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 589E9C3DA63 for ; Wed, 24 Jul 2024 07:04:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 746F46B007B; Wed, 24 Jul 2024 03:04:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F6506B0082; Wed, 24 Jul 2024 03:04:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BDE86B0083; Wed, 24 Jul 2024 03:04:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3CCA56B007B for ; Wed, 24 Jul 2024 03:04:26 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A24A9806ED for ; Wed, 24 Jul 2024 07:04:25 +0000 (UTC) X-FDA: 82373757690.23.DC19069 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by imf23.hostedemail.com (Postfix) with ESMTP id A2FAD140029 for ; Wed, 24 Jul 2024 07:04:22 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=A4jK8Yj9; spf=pass (imf23.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721804615; 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=0NYBHprulQZtHPnfTUTw7qiedMYUcVzPoRU8gRrqzf4=; b=HlaQIduemklMoVcM+2IzZE1f0JlSVxoWpg2KWLf7UWex4aJcf3KWoqU4k6eJYgDCg3coMU hPbTLmywpm7SUqsNsHHCSOEWtCkw9Qj1QHJPmsIPPj7XH3lz0USQhLD2BMCkupZ/tVdrCA 7cbjsi11Cbl9brPx8u6ElnEH61F4A0E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721804615; a=rsa-sha256; cv=none; b=bkervLpulX0r3dPmawUX2OXQLCtuGgZh868rbnemCg2st8mI0BKd4bswGb/KnNUQT/JgZw shLol7GQhBRE4WnQbtTp/mMkL4zVvBkK+JSZMDDebOIxRkX025Uwp7Tmyo8TO6w7DsFFbo /9yakHXfmqliZLMsvdFNcammqZGjd7Q= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=A4jK8Yj9; spf=pass (imf23.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1721804660; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=0NYBHprulQZtHPnfTUTw7qiedMYUcVzPoRU8gRrqzf4=; b=A4jK8Yj9lsuTBtXHRz1Qb3dKQ55LaQ6yUkKCZ30r5IlEfWU8hEp9mnDSSf3CQZxH2M5Ruivy7PkWdK4kG/y2Hm51PiocX1cUHzlUU9P1mRfwSA9bZeHNXVjC6UfQY37Z5Wc3gHVD/eqjwiWikKxFQbB4WrGwGl2xt4kmyMzFKnQ= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037067112;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0WBDLAaE_1721804658; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WBDLAaE_1721804658) by smtp.aliyun-inc.com; Wed, 24 Jul 2024 15:04:19 +0800 From: Baolin Wang To: akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/3] Support large folios for tmpfs Date: Wed, 24 Jul 2024 15:03:57 +0800 Message-Id: X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 X-Stat-Signature: 9oirbho74fmm8bgfionswzykwj54zr8z X-Rspamd-Queue-Id: A2FAD140029 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1721804662-91945 X-HE-Meta: U2FsdGVkX1/qU2pE/6XuWvcl9OnUb8sRUuUx4k8XCM+TbOIsshbzJgXk9Nr7HWzocDs5WYFLptt0ODUYMNoIRYkQ+yP7ul+xglecWJcOboEI/jIzh5ba71AxUdedTBMDWZNSpnE3nQjmnS0hFZBtaTOIpMB9B0IBCj2QhQUHtPza8RLmCEU5Kh2ynvWiZTwLAR7srgekC2BtYmlMAkUbmFmlbjnZwys68NO3OeLl6mOz2G3aYetTL9xoyeWidGWvaf8B9Rgv5pQKbJhjEgvRRFPdPqpo7BHIo4C4br1K1B/GGeYshZMiU9CbP0NEYiU7I79yj6PLG1w+7Z4T195SGIL9YnAm5ZAiK8VxBqoUJSPZotWwgxhCj2S8PZFQnNQUn5d9K8dmkFrJhjr6DJSrOALn0cZHF3e/7j+FFqVEKf3wdkw3JpTHVRB0487gwuw4/MkbGKACeBoBhiewXoJ5Z7ri7uLVuVMgEVK8fzAsL5WFUP0zfGYWj8DsSEguCDOe6Ci3Dx4SQw8d9JoyaBm+BbOPcNnIDlic7B79EnxfpA6VK9Uhc26mcVKBt1BYmhyvJqYVtc/O20r/KXiklRpw2L5H4D0/GKQvA+rdC3QBrj/W34BtrSyj7lZRLJl+ARRq5Xyc4QdQtRnM3caIXbQJfYviqz0nt0E6m5wwyQNXo8yWxCQIRSvr238Yd34UlbMNOEVR1Ah2smvGzHpqHJHq0o9L5BG6SjRd1Xbaq6MetcoXkyTQXZ5YWQw8M8d6CX4rT0z5DDzVRcYboXBMv7LsTpL48i7e7vN+UmQTfNLsTaYO/8AZ5+xtB45f7mke3HSP3kfguDuTvvMuKL5WeuXYgOXAmC+Wmmxc/N5hJyeLAPLyeUZ8BBq7VP/vPSiPFfpxnx4x5ju1n+rOmyENia1n1mvovGnHhwpS8uCviAow1rWAsfhC1rH71gSR0Hxka6hP61mEO3caOkajx98RDei RnjmZD5+ 1iKv5eAdgDVrohvY5E5tEz9ar17Moa7rnja/0clR3uGbeBy9RmbftWedcQZe4bmmCy/DD7E2YLFHD60JB2avhxZvqTJbiVZqWoy4y5z/tlEx9VyMk2j9dL7IN6hjjnF7/jB7JmYDWvwh4spD5EiRhFwVi0bwgw2faeYyEykVy0ukff6IA6WdJam5kvbtCzEru24bTLeALbGQiNDSQFlW2dVjpYEPzC7ysd40oKYY/b4y8xFoQP5ljdOKmSNThkgbYEBk8gbPwFYDN29z/kiRATiGn0oqI9U+4U7Bm9Lo6YBpG2zmNGkukJBD3aEGN0TIK3AgO 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: Hi, This RFC patch series attempts to support large folios for tmpfs. The first two patches are based on Daniel's previous patches in [1], mainly using the length in the write and fallocate paths to get a highest order hint for large order allocation. The last patch adds mTHP filter control for tmpfs if mTHP is set for the following reasons: 1. Maintain backward compatibility for the control interface. Tmpfs already has a global 'huge=' mount option and '/sys/kernel/mm/transparent_hugepage/shmem_enabled' interface to control large order allocations. mTHP extends this capability to a per-size basis while maintaining good interface compatibility. 2. For the large order allocation of writable mmap() faults in tmpfs, we need something like the mTHP interfaces to control large orders, as well as ensuring consistent interfaces with shmem. 3. Ryan pointed out that large order allocations based on write length could lead to memory fragmentation issue. Just quoting Ryan's comment [2]: "And it's possible (likely even, in my opinion) that allocating lots of different folio sizes will exacerbate memory fragmentation, leading to more order-0 fallbacks, which would hurt the overall system performance in the long run, vs restricting to a couple of folio sizes." 4. Some hardware preferences, such as for the ARM64 architecture, can better utilize the cont-pte feature to reduce TLB pressure and optimize performance with a 64K size folio. Using mTHP can better leverage these hardware advantages. Please correct me if I missed something. Thanks a lot. [1] https://lore.kernel.org/all/20240515055719.32577-1-da.gomez@samsung.com/ [2] https://lore.kernel.org/all/e83e1687-3e3c-40d0-bf0e-225871647092@arm.com/ Baolin Wang (1): mm: shmem: use mTHP interface to control huge orders for tmpfs Daniel Gomez (2): mm: shmem: add file length arg in shmem_get_folio() path mm: shmem: add large folio support to the write and fallocate paths fs/xfs/scrub/xfile.c | 6 +-- fs/xfs/xfs_buf_mem.c | 3 +- include/linux/shmem_fs.h | 6 +-- mm/huge_memory.c | 2 +- mm/khugepaged.c | 3 +- mm/memory.c | 4 +- mm/shmem.c | 101 +++++++++++++++++++++++++++++---------- mm/userfaultfd.c | 2 +- 8 files changed, 91 insertions(+), 36 deletions(-)