From patchwork Fri Oct 11 22:34:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joanne Koong X-Patchwork-Id: 13833219 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 49DDDD0EE3F for ; Fri, 11 Oct 2024 22:37:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0ABC6B00A5; Fri, 11 Oct 2024 18:37:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB9176B00A9; Fri, 11 Oct 2024 18:37:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5B1A6B00A6; Fri, 11 Oct 2024 18:37:10 -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 893746B00A4 for ; Fri, 11 Oct 2024 18:37:10 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C35BC1219CB for ; Fri, 11 Oct 2024 22:37:05 +0000 (UTC) X-FDA: 82662783336.15.3A41BB0 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf08.hostedemail.com (Postfix) with ESMTP id 2066616000A for ; Fri, 11 Oct 2024 22:37:05 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hXh3K2vK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728686183; a=rsa-sha256; cv=none; b=XGHRK5t5hD6Yn7zAv1wlosncyDjgBIR2OQv1z2/i80RVrR114Kk3nvo0j3M+CJtrhHESIF pwQyd5BtAmgUwM+mSS2cmhlWpDgMYbGt5qiiXDrkgVGAVjuzF7KUK2b0NFqIDohquiHf/p hfr7+0aD0GXVpDaDqYQtfNhFUrjE7Wg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hXh3K2vK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.128.181 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=1728686183; 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:in-reply-to:references:references:dkim-signature; bh=EVBwS0kB/21OlCWBOP74hlFI7tXMz3WpRGWEmLnozGQ=; b=bDBAadTLv/kIKXIaKyxuMzYt0rYnnRLrQBV0ax/D9aJCbWbHMzpy0wxPRI+11Im8doMcQp B6ANABWHiDB9doOx8SymENCyoxdskNUeF4gI4FvAWxV6dXIF383FL/vdTUByK9VOJ7aaqG 9RScmVVUdZuA2HLyQhlEpLW8aOiCNmQ= Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-6e2ef9af517so21110297b3.1 for ; Fri, 11 Oct 2024 15:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728686227; x=1729291027; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EVBwS0kB/21OlCWBOP74hlFI7tXMz3WpRGWEmLnozGQ=; b=hXh3K2vK0tCr69/bdt/GodS4v2HTUYqloGWpK5yRUXXsGnEIVQ3tRzMzNiKi+nMAas ZLNkwxXbbzHLe+PIXViIEU4Z+vUYLKuvw+B8/wewJ2PMh7APF0XSvONwuLLqE2pE7VBf FiZrJJhRupUB2DgLdHl0oKPQJagln0+kDWW9DoS3Lj2p8o1F+xwY20nLe03PQghCPO8y j2CjNZ2MDxSb7fff24q/Pmyh/yUXDVXN9IJysvRmef2vjPRXqtYHKP9GrkfFuT4rdO0T x+14NQSWVtdnUZBqdyZPh1YN+h0jCIr8CJaPtrfLj+QIYGrG+MAEx6HIxT2N1M7HukEq xIDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728686227; x=1729291027; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EVBwS0kB/21OlCWBOP74hlFI7tXMz3WpRGWEmLnozGQ=; b=dcBr2xeDpDGoVuUdTODXcR9of/Bq53K4V6bKHfJURS5PKBE66tSRPVFpXLxqzyYdE5 shuVTeWuV/9KIWn2InCSw4Xyjx94uKSafcYhuFKiS2CeXTnlYTVuRx5TrDnd5W80Wcho iWNUbBvZ45wAvcXXP9gUDVY6vzCQiWM7ur/p7xqUbOB7hk+d+GFgDKcKgoxmv8TOnRHm RNaw1KoE2vR5k20NzkJ2zDHXO8DsPJjKIt558id3+BVSriCcsSb70S3pDa8szGf33z17 fCuyjy5AK+IW9RfBHUvj6JrKrz0ann9wHn5gasEYeRBQxwsrKoH7Vqrcice4ny8FUXbx It2w== X-Forwarded-Encrypted: i=1; AJvYcCVFrmeSy+pp1dn9avG/25xMlPIZorBzBCb8NAnq00ao9codv+JL4tLYjga21e9ELSkQ1qNJx7rOew==@kvack.org X-Gm-Message-State: AOJu0YyFuE6LkjjDwGsFaPoXwWxH85ICcrmd40VfKzJ/VFmadgTCogKC pjrwZZwdXr4FeLk2S50bOaqJBmh8sbJYvYftMtZoJJHTbTgWdmZ5 X-Google-Smtp-Source: AGHT+IE2ggII9zuF93xLkN5tvo1f9eFYdZNuT8JapHPFW9KMeFDqXbm+s7xph1uIjxQ11M/0r9QoNg== X-Received: by 2002:a05:690c:2892:b0:6e3:21a9:d3c4 with SMTP id 00721157ae682-6e3477c05ddmr28910037b3.1.1728686227375; Fri, 11 Oct 2024 15:37:07 -0700 (PDT) Received: from localhost (fwdproxy-nha-113.fbsv.net. [2a03:2880:25ff:71::face:b00c]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6e332bad6dasm7703447b3.73.2024.10.11.15.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Oct 2024 15:37:07 -0700 (PDT) From: Joanne Koong To: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org Cc: josef@toxicpanda.com, bernd.schubert@fastmail.fm, jefflexu@linux.alibaba.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, linux-mm@kvack.org, kernel-team@meta.com Subject: [PATCH 1/2] mm: skip reclaiming folios in writeback contexts that may trigger deadlock Date: Fri, 11 Oct 2024 15:34:33 -0700 Message-ID: <20241011223434.1307300-2-joannelkoong@gmail.com> X-Mailer: git-send-email 2.43.5 In-Reply-To: <20241011223434.1307300-1-joannelkoong@gmail.com> References: <20241011223434.1307300-1-joannelkoong@gmail.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Queue-Id: 2066616000A X-Rspamd-Server: rspam01 X-Stat-Signature: 6icwz61e7gh81a6yco4ngdtc55fuqb4a X-HE-Tag: 1728686225-987476 X-HE-Meta: U2FsdGVkX19PKPE6ZYqp330R3rA2qbqtys7/FP3dYoIa83ppixe8zlDlS5woya/ptSejQchXeeKGUFl6TbEZntrwH9jyREHLcxuUqAdsal17iidKX1KX9jEhGEKrFNFCu1+gYDqDvO2NFrj9mqrKPNlO3oKEPYMuB+e1YC7BNuZB7OV05zj9AmDBS+2RO41Vmupma36buL2GAeIicHWlCwz8ksXyMVQYcvkHh751RxhRquhAWV7KqAoknWF2fD6TMRlW46nSRm/dT8ZIc2HW3/35F/iRIEvVruveaJ2DyNPQlglTTwWY75c8GRzfeY2wrxPg/Y+XPvYDGCHV2jg4i8iVMH5I+hWVtcoyNCTBxiDmRkHHjCDBVAzYozCcPWRXbvKX4Y9goQ+pRDz9c6WIYTx1dXIKLQdNeJz6Kd7HBx0OPIzhyPeN3MoDOOh4Lz5s8lKKTJDPDBBb5d1DufrEdZI3evALLQp48/78tbGBxCtjGRyqo4i+harHvl4/SalDfk+tJ0vbr9L+E1/B5ekBsPBFSqXKcFKSlrZXXs4FS+K7RC5VetPHJ0IBEp7deGCMPb6ORRV5A7kWLKkd7FlfICJH+OOVEG3qMKSojybz5gaJOYdwM3PsO5IEn0MnJ1sz2+nrQcDB5l3SrsOpZ0lY0czIy5l4bNZ7OyNWpYQ9G3PblMhA6rE47I99j+MKRWqO4oxNw3U7n3WfYls7InS+M/3vtDQn+al+7pA1onUuZEs0mZpMHOQK+ZuOfDgbtU1zFVCB0HL2/0KRXlga/jrCbgDVlHkCUa5o9/kteq/VfTJpeGL6y28ahTFKeETXS3lYKbHuxQVpOtjDnK5pMaLJVtqgF0Z469tlo+sThT+M7/DZNpvM3I19uVFwGszqwPUlNLhxI627cbladXhvAMsBlRn2mNhxZhxtgq17asKvS7UTdx0NPPs6fyhNn8ihMv0DfJ7bZTAavRgmNXxxDYN V+YYCtmw /fotuWjf3zIaD/CoM3Q0iFs7QYqZM2o5ySrOlcoBcnOJqFxZREogOZOZS56ajMiUh9b63HQX5lfwWqkI2n5hjFt61Hj5srCQ6A4O25jifcL5cFTR3T5sL2dth7o7iDfnSM2zoqAie6PztA+Ben1dCH27g4xGoNgmeuPGSfhr2pg6X8zP6vrNleBbxkD4i+Qoa6dlwb4NiJOJcESL0XMSJigdFvqROzY6Ga1LTD7Gejun0mKY619s5ASlg39EK1dUjqMoMy0k5BEGSQHv9nUrjlfSVtAjdkFXwwDuqe0RL3qckJV56pUNCIkWfiWtONU5EXyiID5/h3x2HiwY+SA1lCc4gTOjDI51BhqBpa5TjMaTqlgk= 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: Currently in shrink_folio_list(), reclaim for folios under writeback falls into 3 different cases: 1) Reclaim is encountering an excessive number of folios under writeback and this folio has both the writeback and reclaim flags set 2) Dirty throttling is enabled (this happens if reclaim through cgroup is not enabled, if reclaim through cgroupv2 memcg is enabled, or if reclaim is on the root cgroup), or if the folio is not marked for immediate reclaim, or if the caller does not have __GFP_FS (or __GFP_IO if it's going to swap) set 3) Legacy cgroupv1 encounters a folio that already has the reclaim flag set and the caller did not have __GFP_FS (or __GFP_IO if swap) set In cases 1) and 2), we activate the folio and skip reclaiming it while in case 3), we wait for writeback to finish on the folio and then try to reclaim the folio again. In case 3, we wait on writeback because cgroupv1 does not have dirty folio throttling, as such this is a mitigation against the case where there are too many folios in writeback with nothing else to reclaim. The issue is that for filesystems where writeback may block, sub-optimal workarounds need to be put in place to avoid potential deadlocks that may arise from the case where reclaim waits on writeback. (Even though case 3 above is rare given that legacy cgroupv1 is on its way to being deprecated, this case still needs to be accounted for) For example, for FUSE filesystems, when a writeback is triggered on a folio, a temporary folio is allocated and the pages are copied over to this temporary folio so that writeback can be immediately cleared on the original folio. This additionally requires an internal rb tree to keep track of writeback state on the temporary folios. Benchmarks show roughly a ~20% decrease in throughput from the overhead incurred with 4k block size writes. The temporary folio is needed here in order to avoid the following deadlock if reclaim waits on writeback: * 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 (eg falls into case 3 above) that needs to be written back to the fuse server * the FUSE server can't write back the folio since it's stuck in direct reclaim This commit allows filesystems to set a ASOP_NO_RECLAIM_IN_WRITEBACK flag in the address_space_operations struct to signify that reclaim should not happen when the folio is already in writeback. This only has effects on the case where cgroupv1 memcg encounters a folio under writeback that already has the reclaim flag set (eg case 3 above), and allows for the suboptimal workarounds added to address the "reclaim wait on writeback" deadlock scenario to be removed. Signed-off-by: Joanne Koong --- include/linux/fs.h | 14 ++++++++++++++ mm/vmscan.c | 6 ++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index e3c603d01337..808164e3dd84 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -394,7 +394,10 @@ static inline bool is_sync_kiocb(struct kiocb *kiocb) return kiocb->ki_complete == NULL; } +typedef unsigned int __bitwise asop_flags_t; + struct address_space_operations { + asop_flags_t asop_flags; int (*writepage)(struct page *page, struct writeback_control *wbc); int (*read_folio)(struct file *, struct folio *); @@ -438,6 +441,12 @@ struct address_space_operations { int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter); }; +/** + * This flag is only to be used by filesystems whose folios cannot be + * reclaimed when in writeback (eg fuse) + */ +#define ASOP_NO_RECLAIM_IN_WRITEBACK ((__force asop_flags_t)(1 << 0)) + extern const struct address_space_operations empty_aops; /** @@ -586,6 +595,11 @@ static inline void mapping_allow_writable(struct address_space *mapping) atomic_inc(&mapping->i_mmap_writable); } +static inline bool mapping_no_reclaim_in_writeback(struct address_space *mapping) +{ + return mapping->a_ops->asop_flags & ASOP_NO_RECLAIM_IN_WRITEBACK; +} + /* * Use sequence counter to get consistent i_size on 32-bit processors. */ diff --git a/mm/vmscan.c b/mm/vmscan.c index 749cdc110c74..2beffbdae572 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1110,6 +1110,8 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, if (writeback && folio_test_reclaim(folio)) stat->nr_congested += nr_pages; + mapping = folio_mapping(folio); + /* * If a folio at the tail of the LRU is under writeback, there * are three cases to consider. @@ -1165,7 +1167,8 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, /* Case 2 above */ } else if (writeback_throttling_sane(sc) || !folio_test_reclaim(folio) || - !may_enter_fs(folio, sc->gfp_mask)) { + !may_enter_fs(folio, sc->gfp_mask) || + (mapping && mapping_no_reclaim_in_writeback(mapping))) { /* * This is slightly racy - * folio_end_writeback() might have @@ -1320,7 +1323,6 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, if (folio_maybe_dma_pinned(folio)) goto activate_locked; - mapping = folio_mapping(folio); if (folio_test_dirty(folio)) { /* * Only kswapd can writeback filesystem folios