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 404AAC83F03 for ; Fri, 4 Jul 2025 22:19:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D652F6B00FC; Fri, 4 Jul 2025 18:19:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D14A96B00FE; Fri, 4 Jul 2025 18:19:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C03DD6B00FF; Fri, 4 Jul 2025 18:19:02 -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 AFBBE6B00FC for ; Fri, 4 Jul 2025 18:19:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1732F1253DC for ; Fri, 4 Jul 2025 22:19:02 +0000 (UTC) X-FDA: 83627998524.05.2F5DC16 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf15.hostedemail.com (Postfix) with ESMTP id 67CF4A0003 for ; Fri, 4 Jul 2025 22:19:00 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XrI+4HPR; dmarc=none; spf=pass (imf15.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751667540; a=rsa-sha256; cv=none; b=uyS+ka6gYzc2LNSWAqlI+Vvbk3e/lxH86iwvGbBID8l4oWRjXXOAGQnRfYZcVqCMqEJ0Py JbvYGYuVTYGFqx9YbeGMhVsygZ2edxXO/b1K9XgsZS2J0ckp/lQxYdrFivdx8MV5DkaktR b+hNq2jyd4EVlLwshH/ZLzLfqK/10Lo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=XrI+4HPR; dmarc=none; spf=pass (imf15.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751667540; 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=0e4f4M0fKBmTVU1PrsXGYX/fpoFCkQTfEedugk9qkeU=; b=14q155pmfujkXrUQNBgpebD7fG3uWtdaPjlyx4qHDurkbHeo+YnMUbstcyZdCvAdjrz/LQ 5/ofVOXDT3n6sC1zsPC8H3Gc6nYxlfRqpkXq4oiOtTP5KMrUB1oG8HafQu1JOjy19yabGZ 4v24DTMa0/fSyDH3mhtQOkQcS8koHuY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id C82A46146B; Fri, 4 Jul 2025 22:18:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2857C4CEE3; Fri, 4 Jul 2025 22:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1751667539; bh=FMf4yoXOBgzhcwgHrVEBf0biqD0n/qMzJWPz1SWijcM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XrI+4HPRJ+623pMTvyGIRoDkX71TJvvxw94bykMcExYog7ze9ggr/OLSpIWVmOVC/ 83ZVmDRZHZam9gt62/LjxrT1fZbSdxylewDmDLQkqfgP7FeIYcbuFve0H6ojzuIBfB /Bax2u4lKcyPwqxhqwg6N1ZmV2nOIzPf1JFoduCU= Date: Fri, 4 Jul 2025 15:18:58 -0700 From: Andrew Morton To: Baolin Wang Cc: hughd@google.com, david@redhat.com, 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, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: fault in complete folios instead of individual pages for tmpfs Message-Id: <20250704151858.73d35a24b4c2f53bdb0c1b85@linux-foundation.org> In-Reply-To: <440940e78aeb7430c5cc8b6d2088ae98265b9809.1751599072.git.baolin.wang@linux.alibaba.com> References: <440940e78aeb7430c5cc8b6d2088ae98265b9809.1751599072.git.baolin.wang@linux.alibaba.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 67CF4A0003 X-Stat-Signature: t3ksinjbd7uwt1h3crmrn7w51b4p1qzx X-Rspam-User: X-HE-Tag: 1751667540-423012 X-HE-Meta: U2FsdGVkX18AElg9EiqQcizQ/jRY+7REM+ExCBqdu8yuxqGfalhgmN5QVErqwPyLmxuIBlFDw4s0aq++WWiaM49Pj7PWbk6fCsxVS9RsKhvwyCW+/VUEuutpSx20urTC2CdkE3wwepA1PVxf8GgndslOY5OHYutyun34BCz4AiijkqK1yJZtARnw7+9mnszgCjOPOQ7yT49J8u1V3xZ3KOVXNbcrowD/XzksGj3c855XHTq+INLYoIAcTmfMrNJ9utj+ODzUnImMldEECKehvdf+zKo2Y/xNJ9Yj/Flm4L1Kh1URnRv/PdSFRqOAGl+YMUBWYDpOXV4kf4a5t7jB9BfllEqA3lSJpJ6LCKRm8GtMT0N3dzX0H7AXVW05EQYBHkTjh0q+kgNabZ6qQdx0MytTcXm8ETu5OmTOljBImZqS+zy1d7ZGIn8nROrCsVTanK20+Swm39naqzKdctWUB6g2b9E2yEzLDeZqpc0ETt66C+Zy/iLfZLfylNt9kxwFrYWMqq0vQA+Ky3OdQZmkn2wsLANf5nTwAMhgu1f0P8IeFYUJSHuK/TAtD5eSvf8Ab14unH0jFCy3fEMlrFN7EPVyy1OpzBKgcbbrRUI6hIGlmPE2GT9UEUpUVro8ZYUt9aI+tzzds91ypJ++PU6Suf3vJdaGhDzTvZ9Xmu6ftf0osaQDGNEzI6o3f9r1L4ubcfozjDp62zeyqudJFU/QExVF4pdevhwspHA0IdpVk13COJrSbyw/2N4jCA+btWp7IRov6ssaL/SxdCdgKJfdgWxNS8YPbSFArz1VAoK8yNtgGtnEIF6ct0bd8Ogk3Kx4yNiFqQwgafp7IF0Yoc57vGbn8ncuSMgakjoXmHvZ20uFpN7e2Qjty0amrJsvZr5Q5APnh+8mTsZCWusD5Qswamd6TiPPdAn1CeMK8OU+alSWIhCCBUWQK+JpVNzT44FXt1ckyI5W0DHYStyjaZG oS/KM66G zR4PEIKp8qRijUrNDkNxFxGVfWGjA3NqZHmTgV+F/woEUEpEmMi8fWyEj7Yhmj7YSsSYo+eZk7PPGIt65hryfQYrFh2HgLtbj2sbxL/1JCW5hPKiZ3qwDMQEBGZ/MwZzDKig3LV55Qs6e/+U52Mh3ED92fchEs39FLCI+wnMKtbg8mWhtVqt4KsnbQZablkt7LV9k0d59oNudxbXr7IhPwRGVVy2ILs/deQADlQMfXZIPuJofbb3MbhiBt/hm3FHMQ2D1Iv22KCMIeSDkbBKwB/MSXA== 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 Fri, 4 Jul 2025 11:19:26 +0800 Baolin Wang wrote: > 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: That doesn't sound like a crazy thing to do. > Before the patch: > real 0m0.158s > user 0m0.008s > sys 0m0.150s > > After the patch: > real 0m0.021s > user 0m0.004s > sys 0m0.017s And look at that. > 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) { and that's it? I'm itching to get this into -stable, really. What LTS user wouldn't want this? Could it be viewed as correcting an oversight in acd7ccb284b8?