From patchwork Fri Nov 22 23:23:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joanne Koong X-Patchwork-Id: 13883702 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 323C5E6ADCD for ; Fri, 22 Nov 2024 23:24:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D6096B0082; Fri, 22 Nov 2024 18:24:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 486496B0083; Fri, 22 Nov 2024 18:24:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34D5B6B0085; Fri, 22 Nov 2024 18:24:27 -0500 (EST) 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 14C5D6B0082 for ; Fri, 22 Nov 2024 18:24:27 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8BCDB1A166B for ; Fri, 22 Nov 2024 23:24:26 +0000 (UTC) X-FDA: 82815312132.09.E8FE446 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf29.hostedemail.com (Postfix) with ESMTP id 945FB12000B for ; Fri, 22 Nov 2024 23:24:24 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D6nbhsoJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732317864; a=rsa-sha256; cv=none; b=YPJshn6Xo+ReNAir5Ax7irEwHxGixGKS8spEmIdEPfx8MQ81PUggUgb/tAEcdmFEres7Rv OTLJ3GXYpx9A9j9DFVMnQuBNuMbqNTRyLw3zZw9NSGYSDkhHMgzqZo34UNjCK5Hb3x4TIo eK2sZsQEMLalib0PtSn5WF8Fbrx4ugU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D6nbhsoJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.128.173 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=1732317864; 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=mCcxFgoC08WddjgvVQJDhFHo6qtZVyPlemIEDQaPX6g=; b=ck80TOVoPFNmVLpi6LCitoqI1MbuJrHqJaAB+ewhgncTx3wLPGNUJ5klLwnHVoqdLIToDs nAmPIMNbbeqPVnoO0pQWmKJ2uvNCq4lleNrFG0ciXhK8nTEVje1Q7JoJ4vTkJWByPMcv4Q Swo4JmeBrQscQ2InSK1kznOUalAGM+E= Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-6ee805c96dbso25705677b3.2 for ; Fri, 22 Nov 2024 15:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732317864; x=1732922664; 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=mCcxFgoC08WddjgvVQJDhFHo6qtZVyPlemIEDQaPX6g=; b=D6nbhsoJp+XhjyH1jA0SOcwLwGDNf50aoOTE6+70hcXZs4zPTSXs/1VaUZVvAVegbn gbHb4pjTR/XrPkA1psvFDjylCsh5TULP/GUTfGkOZyZkOsQYxfEEDP0y+9Jbyvf5wzSC FmI4SF43wDjN+FqHCnwL0G94jTzB0XHX7Lfor8mQ3pKj985QNdFjaQMdE/Ol8pyduSwo q6+Qo2nwdDqLpVp1UHLFdDNN6YWiOKZ/fO4IPKliMjguIAt2tnBmUzanAT6IwvnaPvuW /DK2P2JS2IxNwKZYIX81npHMSVCNIEVngKh7u3oe7ayGEUS+SVqZF5X9N9G3j1Fu3miV zPog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732317864; x=1732922664; 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=mCcxFgoC08WddjgvVQJDhFHo6qtZVyPlemIEDQaPX6g=; b=XIAOOtPXxD/SIxR3I03og/3KSQ1OBaK85np7VVtwzNru2srNCbMuurv/AFiSTNJKTa q+pAW4Xn/jDtrpQIDctjRDdRzB9LEKijZLIz2pehFr6ftuVgCPucsj3RPiL+IhIML1Hz mO0ZK6lXPBdntviOni/v4fpRTMJGuk6Pfs1OTkMeoowhPTUmu0gzBAMUHUcZjf7iqpS8 4LQj5KlZbyv6QHZC+GV3c23aSCHksQQS/CdgTRdmSKvLA0PAN9ROyb/VBTGULJhmSLFn V/vk5/Gp1LtSjP9rtyVe/yvIQ0HThUHooSpQ/33puARvo0LwawrLp2ezY9G/imXndgmr AOFA== X-Forwarded-Encrypted: i=1; AJvYcCUlY0cWEybnlijbNZnuwSxoqmQ2xxL/Kuuwkai0JcACFZwVMT5Oy81oIKgOB+DyYFlkWd+0hYHvYw==@kvack.org X-Gm-Message-State: AOJu0YyBQYCQjjEo4hRvns/oZERWlCixXE7ur2hJO8Xfv1cAF9H6x/Zq YiCKkqOJQ1PS3nl8oda+tFw4/6B8nvt2/btq9XAXMkgBCGwrrYj2 X-Gm-Gg: ASbGncvIzz6pPOS5ZsWXuZfgH1VzoFEt0YZTWemr2HbzbMsVUg5Ts5p2yGuubMYvv0Z TcWNHmExYHe45pXl9BuBH8DRr5b5HvGUtUomuFU5RavvKlxMGzNQEkd5fcoKMuL9uiIt9p9MzBo foWMLribvWWmaKV7lrH3DUoxzmvT8/04f8RlUmBmqBpU2zzf1a++OUsbGSy44jZiydgpUv2tfSB 3VVWbiSStj0DViBXrEZ4/QBrcN/tah4+Me15i1l/oVZew+60ZVGfZxhxpmkjvd/I5qb0Z1hHWl/ ARYLzWn7iw== X-Google-Smtp-Source: AGHT+IEq4lVU89WONK6PJHk6F5A/Atbo44HCgzN+1qkcDp+xp+kLy/RNIRz5cIx6oN7Ci5cVSnsqjA== X-Received: by 2002:a05:690c:700a:b0:6e5:bf26:574 with SMTP id 00721157ae682-6eee0a49959mr57594887b3.27.1732317863681; Fri, 22 Nov 2024 15:24:23 -0800 (PST) Received: from localhost (fwdproxy-nha-114.fbsv.net. [2a03:2880:25ff:72::face:b00c]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6eeeebc5d93sm2170897b3.116.2024.11.22.15.24.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2024 15:24:23 -0800 (PST) From: Joanne Koong To: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org Cc: shakeel.butt@linux.dev, jefflexu@linux.alibaba.com, josef@toxicpanda.com, bernd.schubert@fastmail.fm, linux-mm@kvack.org, kernel-team@meta.com Subject: [PATCH v6 0/5] fuse: remove temp page copies in writeback Date: Fri, 22 Nov 2024 15:23:54 -0800 Message-ID: <20241122232359.429647-1-joannelkoong@gmail.com> X-Mailer: git-send-email 2.43.5 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Queue-Id: 945FB12000B X-Rspamd-Server: rspam01 X-Stat-Signature: 66u4inucz9fwsof3uh8q93hau684arj9 X-HE-Tag: 1732317864-950182 X-HE-Meta: U2FsdGVkX1/qH+obeNo13XaozQWPinEgJnhB6RS8pG1OPb7m215MsZn0skIPm6OnsQDxcdIV7tkYfLF+oIDfP7XIttNFQAB1FK06oRYtNp9rcENAjTX6bRlI3ZCZai6pfsEM74qrWWk0u+qQbjrWubvW2p1tzj40ZlrFBfTdnACmn/d/8q9MYU8wuhryvE4A1Qwv2bby+3N0HIGHZ3e3D+zDipg1MyN0KYU4LK85/9WDsJmiadKSbe520xqllGcUYmQfkan1Vdq+WOv69nDkIZBK2eV00unlLerfJ8u7ET1eCwbjz8aptXDa9ilkECOCE7xL1gTxDyW0GaUB8Vhgs//KjEIv93VQenD2F6zvtXfNGbbXtBbZ/xTvIy/sL88lPS6PoIfe1V9TnlHY+Uny77qqFnr+R1ibZGVZa7cUm0jxd2z8uFg/u+s80Defr9O9YcjclGE4d10kMmUTYZtTDCnOY+swuTFjgQNz1uZTFVDZDd499pH78EnoeO6FMc+11mWwCtM3vP1CpKwSPCFVnYQrsRly54xXeaU8C+WgPLGrEstr8GUQ+VOCBln/Q8vI89DKAj1mQEGdmaelKZGDp3VuKmPYTuR6Xm/r88dWDx/dAzoFfShFh8xSTUGUuBfY2jDCrobOuYapbg+wu53Lwo/ropPCA31oHg2iCNxIcwYd1ma7zEOfimHW4X2e1Lsg4Kd86wORNAJKBBI7eQ9R+BGrBrMWMzt5QR2JHW+nH+z9zMBLCvY4t6Frx9SAyirgpGsGtLgI0LON1G+Zumt9pKM9ZTgggJkJTsC4SeCpgTH97iUV3zJq8RttuNBrm4BtMLkgy6nCdyBwIYDDTn2oyD0n/Fa8erv0gsKuEvQAP+cSpDuCXBo9dYZPrYxs02xnb/yj43fX2HqyMCI5xK/EaL24fZJMHwMGtHUiGPcoOUUPTtV1b4qmYAL0ZkRqh4QPdhc+a17Oph84d4OWBuX G9Fs5NvZ 2XKZH4XHRxg+8x32LE2p05hvu26XaSoJMgrvKBOKnP2mH39pNu3nZApE2l43aG+CfraSCaPj/bNXD1V5YKmglLyO1y6Vxt8g07jbLoGAkQkZAP3uf+pW5c0dzOAahoD0uTuxl0mEHhTuZy6X701UgO5fgc2NWDnhLWjQKDu7X+u89bjncVQFXpdOoqMoS4C7+lmJT95dzIyrvN1XlqpGiMh6QxfL6KlNkRlIRHXYXobaZfY/AFL9/YIhL2JJuDJKtTy1FJH6Cmlr8r38sGIuGIDW4V1iXwtAupxBGW5oYGE++eGT7dmUDHxT8zcPf9aUl5eAqXxsPMWP4le4h+Lq4ap0NIWyHBA6PX/XmlxH3RA4me8IuaC/0LOJUCA== 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-cache write performance 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 for two reasons: a) 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 b) in order to unblock internal (eg sync, page compaction) waits on writeback without needing the server to complete writing back to disk, which may take an indeterminate amount of time. 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. With removing the temp page, writeback state is now only cleared on the dirty page after the server has written it back to disk. This may take an indeterminate amount of time. As well, there is also the possibility of malicious or well-intentioned but buggy servers where writeback may in the worst case scenario, never complete. This means that any folio_wait_writeback() on a dirty page belonging to a FUSE filesystem needs to be carefully audited. In particular, these are the cases that need to be accounted for: * potentially deadlocking in reclaim, as mentioned above * potentially stalling sync(2) * potentially stalling page migration / compaction This patchset adds a new mapping flag, AS_WRITEBACK_INDETERMINATE, which filesystems may set on its inode mappings to indicate that writeback operations may take an indeterminate amount of time to complete. FUSE will set this flag on its mappings. This patchset adds checks to the critical parts of reclaim, sync, and page migration logic where writeback may be waited on. Please note the following: * For sync(2), waiting on writeback will be skipped for FUSE, but this has no effect on existing behavior. Dirty FUSE pages are already not guaranteed to be written to disk by the time sync(2) returns (eg writeback is cleared on the dirty page but the server may not have written out the temp page to disk yet). If the caller wishes to ensure the data has actually been synced to disk, they should use fsync(2)/fdatasync(2) instead. * AS_WRITEBACK_INDETERMINATE does not indicate that the folios should never be waited on when in writeback. There are some cases where the wait is desirable. For example, for the sync_file_range() syscall, it is fine to wait on the writeback since the caller passes in a fd for the operation. [1] https://lore.kernel.org/linux-kernel/495d2400-1d96-4924-99d3-8b2952e05fc3@linux.alibaba.com/ Changelog --------- 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 (5): mm: add AS_WRITEBACK_INDETERMINATE mapping flag mm: skip reclaiming folios in legacy memcg writeback indeterminate contexts fs/writeback: in wait_sb_inodes(), skip wait for AS_WRITEBACK_INDETERMINATE mappings mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings fuse: remove tmp folio for writebacks and internal rb tree fs/fs-writeback.c | 3 + fs/fuse/file.c | 360 ++++------------------------------------ fs/fuse/fuse_i.h | 3 - include/linux/pagemap.h | 11 ++ mm/migrate.c | 5 +- mm/vmscan.c | 10 +- 6 files changed, 53 insertions(+), 339 deletions(-)