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 DA675C8303D for ; Fri, 4 Jul 2025 03:19:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 584C26B0101; Thu, 3 Jul 2025 23:19:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55BE86B0102; Thu, 3 Jul 2025 23:19:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 498D86B0104; Thu, 3 Jul 2025 23:19:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 382456B0101 for ; Thu, 3 Jul 2025 23:19:45 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B4A45108AA5 for ; Fri, 4 Jul 2025 03:19:44 +0000 (UTC) X-FDA: 83625127488.04.D901C8C Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by imf13.hostedemail.com (Postfix) with ESMTP id B868620011 for ; Fri, 4 Jul 2025 03:19:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=QYx64v5u; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 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=1751599183; 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=kNobNAICq8OI6ZolSBIkSCMUrxwEO4uU25FQrzVKD+g=; b=rNLeaKpg02CFZBh/eaXISQK9FFrjoTlvhkNdF8l9sXUwoVHEl/6k7thP7yLhPGltutm0YO HrPKoovIMZhkslSwHMA03s3A1nPocCQ1xxjw7znbf0mwHmHrMe60UjLBjsTwP1EPo5ZYM8 eNeMQ9YnKYMeXY0giZEIlGVGdrbrPqM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=QYx64v5u; spf=pass (imf13.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.133 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751599183; a=rsa-sha256; cv=none; b=yPGYjGUedf0LfD7jFtU7KonZVNDo8cov6NAIFkmvwElE1zJj8BoqYCVG+HtTLSP0oCarE1 tS5K4dupgwFGaQP4vQnJjZqH1RHD/86YnCScaNc/O18tg5UUfru2rfmi5zjVgMUcXc341R 0rSdhQmEtrAX+IeM9i00P77MFQlAHIo= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1751599177; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=kNobNAICq8OI6ZolSBIkSCMUrxwEO4uU25FQrzVKD+g=; b=QYx64v5uT16zOlJRUAur73wF1BVxePDctDe9WG3RtpFZ1Ic2dOy16pz15Ij/4lkW2Gxa8UF9pitK0eA0PDJDf4yL4huDIacD57outTnwuD1bMCQza/F7ZST34optsfEJ0xsvD8Dy0r7V2ySR4+KjW44a6MsEYg4x3/qlvrmB+5E= Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Wh93g4-_1751599175 cluster:ay36) by smtp.aliyun-inc.com; Fri, 04 Jul 2025 11:19:36 +0800 From: Baolin Wang To: akpm@linux-foundation.org, hughd@google.com, david@redhat.com Cc: ziy@nvidia.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] mm: fault in complete folios instead of individual pages for tmpfs Date: Fri, 4 Jul 2025 11:19:26 +0800 Message-ID: <440940e78aeb7430c5cc8b6d2088ae98265b9809.1751599072.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.43.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: yh6i1pcpqjn9pgo48dxtqjbdirfbcc68 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B868620011 X-HE-Tag: 1751599180-323102 X-HE-Meta: U2FsdGVkX19GekR7zhcHZKpfgdoEVSmwQxe8V70GbLTyOgxrV6splmzUzHJAPfOnt2gEKUwYnStcexrcuZPtdsmyJz38aBvs4Yua0jQlomCulML4e2oM8nU5IpNv7S06sZKQZKhjsCu/trVEM6El9X3RI+0VN1lfbXyc8lM8DzQhPISDq0Fx/ayu3QfAQJoOqAt8aKvsezG0yCDD547Z/uYFOLQJ+kwpu2peUjMxpE8sweADKmAhJ0D9RHS/DqkeJ2QyH4FCol68NTJU+gAcwz4b0RlMitT+6Ws2Y7RZlyffuWBy2QM6ouwJitersc+ivT9xPG5wOFmYd5nNBVVVrNkkj8IRii86qnmnbuOV5wjIdT89TC8GaTRP8v3SfTZbIoFam7U+lpBbmjSmKNSCBkiMBytvpFiEv2b2ggBGgOWNNw+ZySCiGd8dMm+lZ+1kaOJehDzRhgSllI6N9j7AfzG9twuAjcljg5+mvqdFKNxMRW3+sjwst1DDgRRlT4orJUAqYIjeOvduBzwT4OgQ8APKv1xCLAK1uJIww0ndX9s5BgxAJhzPFJTJDWlmYC/NetCvU+77Fa9XnYj49SqFbH29wB4jYS4ON6wkWiOsq+gw1VEAPrrsew0z55xcLZr+w6eg2HaiaCE3KSM/O55gDwXja8+kNjaCGidGEyxJVeKVIVAU45G6i3tRmmKrJjj5F4vJpQS6z3WCOEhfXvtFYAVgAtgFCekPp+n6pE8g6ihH+HASTiA+S9rPuI9nVMnqAKR4lpKs0b1PNTVcSIJ4bsb8QfXNJG/xLjblD1GOqyRY19njsqqi1o9yYGshC1SVSrlG6qkdnHkEX2e7TQfHs3J9gXhxK1kVEohDPKATKd2MGq7QpBAP3E7530jRiammtDmXKW7NItt/bGDHDxWurZmlnNuSKQtFgoTZsof8TbLgBeWxdjLjGz9PpB3QxU71PjD5sO3nFJlK83FBuCt q8VQq5Si es0ZApOXBMbQRSjJvcQY/cDUeZ5OeCuioLqSJppuBA7OwgIx1lTgVipMdIZczzbA+EDDBOzo4Uxs6VQLoxyrvSdTgvI12WaK2fb2WoHYqDQcnODLsmbpE8y8c67+lQ1g8XD864sa05itZe2Yotok9ZJh2DwZ5PCOJbuipd3oG8IGb0NrTGVVAdzeJ9l3Uc5qNcTk06EW7RFbWGP+4jVUzn8f02uh/JQvxAnRSNx+ibk2UxXr5JVHeWypzzqtQ6M2dWp8W 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: After commit acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs"), tmpfs can also support large folio allocation (not just PMD-sized large folios). However, when accessing tmpfs via mmap(), although tmpfs supports large folios, we still establish mappings at the base page granularity, which is unreasonable. We can map multiple consecutive pages of a tmpfs folios at once according to the size of the large folio. On one hand, this can reduce the overhead of page faults; on the other hand, it can leverage hardware architecture optimizations to reduce TLB misses, such as contiguous PTEs on the ARM architecture. Moreover, tmpfs mount will use the 'huge=' option to control large folio allocation explicitly. So it can be understood that the process's RSS statistics might increase, and I think this will not cause any obvious effects for users. Performance test: I created a 1G tmpfs file, populated with 64K large folios, and write-accessed it sequentially via mmap(). I observed a significant performance improvement: Before the patch: real 0m0.158s user 0m0.008s sys 0m0.150s After the patch: real 0m0.021s user 0m0.004s sys 0m0.017s Signed-off-by: Baolin Wang --- Changes from v1: - Drop the unnecessary IS_ALIGNED() check, per David. - Update the commit message, per David. --- mm/memory.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 0f9b32a20e5b..9944380e947d 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5383,10 +5383,10 @@ vm_fault_t finish_fault(struct vm_fault *vmf) /* * Using per-page fault to maintain the uffd semantics, and same - * approach also applies to non-anonymous-shmem faults to avoid + * approach also applies to non shmem/tmpfs faults to avoid * inflating the RSS of the process. */ - if (!vma_is_anon_shmem(vma) || unlikely(userfaultfd_armed(vma)) || + if (!vma_is_shmem(vma) || unlikely(userfaultfd_armed(vma)) || unlikely(needs_fallback)) { nr_pages = 1; } else if (nr_pages > 1) { -- 2.43.5