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 17702C369B2 for ; Mon, 14 Apr 2025 22:22:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 830422800A4; Mon, 14 Apr 2025 18:22:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DE37280099; Mon, 14 Apr 2025 18:22:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67ECE2800A4; Mon, 14 Apr 2025 18:22:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 44803280099 for ; Mon, 14 Apr 2025 18:22:32 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 220398079E for ; Mon, 14 Apr 2025 22:22:33 +0000 (UTC) X-FDA: 83334074586.01.299D42B Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf06.hostedemail.com (Postfix) with ESMTP id 53AF7180005 for ; Mon, 14 Apr 2025 22:22:31 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HG9ALYR7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744669351; a=rsa-sha256; cv=none; b=pX7yoXjuNG5GYCgb49EFCZu4Df69A/tPBWgBzPyqezfZe44t6/u9dqSWDGxE2xwI2pNemU aKoGAKEmDd5LdkazLvwDbvow5yjTH209UdRW5qocGOTdTJrLz1vgkKVDB8Esaf7x68sx5W qI2L4s8ExrrzXl2QxuOAMHWJh3aY5OM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HG9ALYR7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744669351; 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=CXyTK49lUIGEYMX0uNAmIhRrzBLysbx4YJ2RpRUIBEY=; b=So4nYi4NbFAzv5kkcqYaK+o1GGNLg/5JSaTbbQHBN/N2UVL2weRaJqEIf5Ymg7cgVHBVCw l13+1nr06kqNi8ySpwqEAstZl1IEgHDm02v9nwcetAX5nkiMABOI9DvE2Fd2CFhnq5oD9M pDesGO0h5VfjAteyZtB/WdKanbEU2oQ= Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-7376dd56f60so3276846b3a.3 for ; Mon, 14 Apr 2025 15:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744669350; x=1745274150; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=CXyTK49lUIGEYMX0uNAmIhRrzBLysbx4YJ2RpRUIBEY=; b=HG9ALYR7OHcCuwD5aHUEFICAT3yRrn+wfEKjHbNpYX3+0vlj9JxTFA5pcYun1MwnRG Ug4aO9F9rW4bwaY0bJu3idnMxiU3ibRywBJfV8JD/8nudpJlleh9Me9oTxaNFEA7J4cW fjgbPUcIN87PvUyKTSSmi1WywX86axxtFWXPdw/D1qYhzZUvBfa99IKiCOiVP8aMOHig Ooz+wC5ajP8wFKFV/+oP8ydSAv4oeS4x+w38YF8FfzBHNbWhba9gZAxTgNuI0D5wC8M5 TNUucJjaLp5zqgyWmtYfBmiYOf9PX2FRLrXhYyckxNIxnPYNoh7xCuUlRc/5q+35suU6 u5iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744669350; x=1745274150; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CXyTK49lUIGEYMX0uNAmIhRrzBLysbx4YJ2RpRUIBEY=; b=NvV9eAXxRhT7oGZQJ8N1xqlkelPIDv2oWXq8O1Q8I0hpTqFsThc6PjUQbPZKRIGM/5 /8IB9MshkU4sxACmt9jakPJaJA0mzVKB6nASvcEX0gxdhVmyeAQeRiiZkWSOqMiiNQv1 152Mc2ACNjecHyqQzRRwZVM1uK6iN5gKI3+cBSf/wbL9DCuEWCjLE0wqUHRRRKIOmy/E 9vghWMhlZVC4ae7+2YVEm3X96jFqNEZqr22MEAxzpGA4d7c7YoQqwkd8W+xwPWb2W5mS xnbEZTz2NvRf4MAGeBhpotvh2h9bamcTbnFdi2UgG/vl7ijW4Kx/1/yfbflk+ifJpY/9 R8Yg== X-Forwarded-Encrypted: i=1; AJvYcCXEq2Oj+TI49mDApic6oCcaNAFNAy8iNiqpjLnmAXbmBicXSfVfrHXV4ma8BwCCJO6FTUBDBwM4Qw==@kvack.org X-Gm-Message-State: AOJu0YyCL7QzS5T06U7gWVzvS+JyGurkplfzVUvo0S4j3Gvd3LdH5zA3 h2Yrou1X/jRKF9Wd4jFtLKs7/hurBzXqrcYoPTvn1wtPcM1vymXd X-Gm-Gg: ASbGncu2IaC1WXIM3oTE37x7JFvnsclfTeBLSERJx8CLBF9h+Pv5o/NGr5YlkfU3VRz WMRbgbFHGfSnthaG3WUWNadvj7uIaQLINT87UQB2RK/MklCrKlqHv6ltnzIk44nWpfu1MhbnT7/ wLGw4+Uqm06z7IQ46Ug5RjiIyOujsyTVOs1iTayJR50SicCB4vlpxCWaVNOktKLGRq86XwmUX/U BVPXVvUdBBBWwRT/211vy0vUXPgGnrtKg9BwjWJF0XDMALVc9F9VYVcTAufeUpFKlBTq89rivKR cL8vfcyK8dSTAG/NFw8r0rwf4mmi6l2YPS0= X-Google-Smtp-Source: AGHT+IG2FugvAZ+utBclVT+TiH0mbGXIvsffVv0W7/ugtCZZzFMpzNcwBH38C4sdRes4hKTNPlETAA== X-Received: by 2002:a05:6a00:3d4b:b0:736:55ec:ea8b with SMTP id d2e1a72fcca58-73bd12c94d3mr21082350b3a.24.1744669350029; Mon, 14 Apr 2025 15:22:30 -0700 (PDT) Received: from localhost ([2a03:2880:ff:9::]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b02a0cf3604sm9873735a12.25.2025.04.14.15.22.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Apr 2025 15:22:29 -0700 (PDT) From: Joanne Koong To: miklos@szeredi.hu, akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Cc: jefflexu@linux.alibaba.com, shakeel.butt@linux.dev, david@redhat.com, bernd.schubert@fastmail.fm, ziy@nvidia.com, jlayton@kernel.org, kernel-team@meta.com Subject: [PATCH v8 0/2] fuse: remove temp page copies in writeback Date: Mon, 14 Apr 2025 15:22:08 -0700 Message-ID: <20250414222210.3995795-1-joannelkoong@gmail.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 53AF7180005 X-Stat-Signature: 4wx7ua8ns81upgj61kwgj9kqbi3xbfw8 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1744669351-380950 X-HE-Meta: U2FsdGVkX1/W5ffi3KepZEHNrI21ZILSYP7npvFPqPlJt138XmN3ocfqJElRNZF2hy2yUARsts0kUfR5LqZ8tH45oyF0krXSAmRGJ+9UcNFf6Mh10kP3F2kQEV+tjrT47NiBnhaqKf21Nf0Brz8ol1vc1KYjweosRUJ+ZtdVhL2fq8GK5FX5SlZ6id7tYtz38finFG9yWwYxbknhLXgaL6Gi0zc04Wq8ZH5LtbBPg85TkzWG/P0RmtRt3PXgMZI+AC7xAQVBPLgqm/QBCxHZZQ4E/A5dxB+jk2wjXEfB8BdqPHanmXLIpGcfr4OFwFcxNz6rbr8CEjIDB1saQuMkFjjsMjIOO4vlZd+KrKbjtNixBAy7WKhnXrQSS6ILCx8sWNxjFIPO8vLHvEaggznsBjjY9i9IgxehzCGQveM8Xr6CzeL4bbGBg5Z0f1LrybOAoT+N12or4pf6mpfgWxqBC5lM4zi+Hb0k1nKS+3/AywpMV59WdEXIHrFdsxNeyqOEVcfWxcRL3ohDl+L8udqkYjP1/XbO2u2vjqzjQUD75aDSnZ28TliACUBwx62AB0fhWG9dlKO7soanCA+gpknfO6CHqz7vdqPFeUt7xbq/eiiIfJyFY+9GTo9u2wrg7Ti2SfAfDcbUnkefJhMvLNnsX8npegCwWDmhM0C48argaRKvTEjWyLX6aHauJ1V/ZzI5RDRgSE8oYwB1UB0XN5knlOgEdyflkHHzsXfhEVmv/f8XUwPD3UC6D6dta6UUPKbc//KR28ujNjtdr0l06xRc4KssFsyq/OWHbeex0DsntvBByhUJLGDn4OaXIUojMKTI4eibqBoF9hD5ng0Uydb6/r8fWo+0/49PdO0Cv6L3BgBNLQg0fZXS6/Z6uM4mjRaHQazCINhOM7tl8MWb/te0t6MKqXB6ZiLFaoC6V0yinv71KspRisWqBehDL4J4RZkz/eHqOZtSQc+iUvhqody TDT1Ar+q NCUjcOFI14xT8sKTzkK7vKQiMxfKrj0fuB3kH+vBTwyFMnDiUjJUlQZzlA2kaX5PutqnQEKwa020nA5qxmQiPC+6Gh2t3yVw63ygzLdE6i4os5RhhGIZSJDpHSTy6s4qvOeiTnNpoh7ktIM9W3aMO15ke9odgi0W3lzFC6B61pD5TSDXZOTCjU2pMpgCLfEhtHDcLErVJYuNmbYFHhOMJ2/4cif7WgXpFpDQqfPEOiikL8Y9vP7mzXkGxUP/YqR9q7B4Cav/v00K/ALLpu2OzXlg7XFtpQSBNHr8ZmNwYPvaIDbIvKwheNSXsgcFRDqadZoOgNCTjK3adiCqARcHZfFlbsDXuErp9MeP4Jw7c73XsRPfzXxiQxZ3HBRSLIrbLDtx1g+4Hwl4ESStEUul30lTD9xgrIcacH9bbuMuk22jMEq4k7ev/ESNLzw== 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: The purpose of this patchset is to help make writeback in FUSE filesystems as fast as possible. In the current FUSE writeback design (see commit 3be5a52b30aa ("fuse: support writable mmap"))), a temp page is allocated for every dirty page to be written back, the contents of the dirty page are copied over to the temp page, and the temp page gets handed to the server to write back. This is done so that writeback may be immediately cleared on the dirty page, and this in turn is done in order to mitigate the following deadlock scenario that may arise if reclaim waits on writeback on the dirty page to complete (more details can be found in this thread [1]): * single-threaded FUSE server is in the middle of handling a request that needs a memory allocation * memory allocation triggers direct reclaim * direct reclaim waits on a folio under writeback * the FUSE server can't write back the folio since it's stuck in direct reclaim Allocating and copying dirty pages to temp pages is the biggest performance bottleneck for FUSE writeback. This patchset aims to get rid of the temp page altogether (which will also allow us to get rid of the internal FUSE rb tree that is needed to keep track of writeback status on the temp pages). Benchmarks show approximately a 20% improvement in throughput for 4k block-size writes and a 45% improvement for 1M block-size writes. In the current reclaim code, there is one scenario where writeback is waited on, which is the case where the system is running legacy cgroupv1 and reclaim encounters a folio that already has the reclaim flag set and the caller did not have __GFP_FS (or __GFP_IO if swap) set. This patchset adds a new mapping flag, AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM, which filesystems may set on its inode mappings to indicate that reclaim should not wait on writeback. FUSE will set this flag on its mappings. Reclaim for the legacy cgroup v1 case described above will skip reclaim of folios with that flag set. With this flag set, now FUSE can remove temp pages altogether. With this change, writeback state is now only cleared on the dirty page after the server has written it back to disk. If the server is deliberately malicious or well-intentioned but buggy, this may stall sync(2) and page migration, but for sync(2), a malicious server may already stall this by not replying to the FUSE_SYNCFS request and for page migration, there are already many easier ways to stall this by having FUSE permanently hold the folio lock. A fuller discussion on this can be found in [2]. Long-term, there needs to be a more comprehensive solution for addressing migration of FUSE pages that handles all scenarios where FUSE may permanently hold the lock, but that is outside the scope of this patchset and will be done as future work. Please also note that this change also now ensures that when sync(2) returns, FUSE filesystems will have persisted writeback changes. For this patchset, it would be ideal if the first patch could be taken by Andrew to the mm tree and the second patch could be taken by Miklos into the fuse tree, as the fuse large folios patchset [3] depends on the second patch. Thanks, Joanne [1] https://lore.kernel.org/linux-kernel/495d2400-1d96-4924-99d3-8b2952e05fc3@linux.alibaba.com/ [2] https://lore.kernel.org/linux-fsdevel/20241122232359.429647-1-joannelkoong@gmail.com/ [3] https://lore.kernel.org/linux-fsdevel/20241213221818.322371-1-joannelkoong@gmail.com/ Changelog --------- v7: https://lore.kernel.org/linux-fsdevel/20250404181443.1363005-1-joannelkoong@gmail.com/ Changes from v7 -> v8: * Rename from AS_WRITEBACK_INDETERMINATE to AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM (David) and merge patch 1 + 2 * Remove unnecessary fuse_sync_writes() call in fuse_flush() (Jingbo) v6: https://lore.kernel.org/linux-fsdevel/20241122232359.429647-1-joannelkoong@gmail.com/ Changes from v6 -> v7: * Drop migration and sync patches, as they are useless if a server is determined to be malicious v5: https://lore.kernel.org/linux-fsdevel/20241115224459.427610-1-joannelkoong@gmail.com/ Changes from v5 -> v6: * Add Shakeel and Jingbo's reviewed-bys * Move folio_end_writeback() to fuse_writepage_finish() (Jingbo) * Embed fuse_writepage_finish_stat() logic inline (Jingbo) * Remove node_stat NR_WRITEBACK inc/sub (Jingbo) v4: https://lore.kernel.org/linux-fsdevel/20241107235614.3637221-1-joannelkoong@gmail.com/ Changes from v4 -> v5: * AS_WRITEBACK_MAY_BLOCK -> AS_WRITEBACK_INDETERMINATE (Shakeel) * Drop memory hotplug patch (David and Shakeel) * Remove some more kunnecessary writeback waits in fuse code (Jingbo) * Make commit message for reclaim patch more concise - drop part about deadlock and just focus on how it may stall waits v3: https://lore.kernel.org/linux-fsdevel/20241107191618.2011146-1-joannelkoong@gmail.com/ Changes from v3 -> v4: * Use filemap_fdatawait_range() instead of filemap_range_has_writeback() in readahead v2: https://lore.kernel.org/linux-fsdevel/20241014182228.1941246-1-joannelkoong@gmail.com/ Changes from v2 -> v3: * Account for sync and page migration cases as well (Miklos) * Change AS_NO_WRITEBACK_RECLAIM to the more generic AS_WRITEBACK_MAY_BLOCK * For fuse inodes, set mapping_writeback_may_block only if fc->writeback_cache is enabled v1: https://lore.kernel.org/linux-fsdevel/20241011223434.1307300-1-joannelkoong@gmail.com/T/#t Changes from v1 -> v2: * Have flag in "enum mapping_flags" instead of creating asop_flags (Shakeel) * Set fuse inodes to use AS_NO_WRITEBACK_RECLAIM (Shakeel) Joanne Koong (2): mm: skip folio reclaim in legacy memcg contexts for deadlockable mappings fuse: remove tmp folio for writebacks and internal rb tree fs/fuse/file.c | 364 ++++------------------------------------ fs/fuse/fuse_i.h | 3 - include/linux/pagemap.h | 11 ++ mm/vmscan.c | 12 +- 4 files changed, 48 insertions(+), 342 deletions(-) -- 2.47.1