From patchwork Wed Apr 17 11:03:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13633210 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9B2913CF96 for ; Wed, 17 Apr 2024 11:03:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351828; cv=none; b=KWS0WUzHwRphj2cywd6ZkgavuHgbJsw1BC+lMyQx+3+xq/JeerDeuKux0gBSaLIZQ8uhs3WmmJRc7JuQk0aa3qKJGCksxFce9AKdocZjIbObHTLxBI/Q4oQcja1O4K37I/NVDXnnyHoUOP72IAnLPvy0/RoMWmoS9OFkmlKV5xQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351828; c=relaxed/simple; bh=PBOiZc/yGTGQpRZy+Y/vY9LFPQbJkuTYshHrGRaLEFQ=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=OOv67CG4nFCIeJaE+RJFsBf4XhOYopmxX1UUboW05gg+iDm81qdzazH7tsTlHgYMu8HGFZ8dPYVfwLhre34EK/2xH18Pghk1N7g0yFS4QqieOMcpa8eE8NAS77GyXKkwCItq4fR74nGb751s2Jx2RnPMqLMPR/62fD1E3QaQkeg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ecOWDI6I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ecOWDI6I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C690C4AF0A for ; Wed, 17 Apr 2024 11:03:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713351828; bh=PBOiZc/yGTGQpRZy+Y/vY9LFPQbJkuTYshHrGRaLEFQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ecOWDI6I+ErOxmwfriQ+oG12V7HqUKl1C08tR2dnIgTtz4zoOmqQGHM2mhis5ykK/ uGRoewWqJlN5u78K/GjzHMNwO7dLlNyfn+DY7XbP9HOsjwVh4FABrtA+/lXOprSVpK Qh5PWihiMm16AdsOKiUaKx2z69ArZ/M/SzVFqaj4LDIvZn1lBj/a951IBTpBaHmbDj qx/DB3z6lW5G1WcAM7tJF0fMaYz1pkwy90/m/J06PJ/4DM8HoK/PjwgAeRXlEv9a+w UD7HreA1SEsb37L1PqItPPK55oTet5Ex243VSiwO3TZ0YAl/oTyxl3ZxpzLobyI+71 vVn2bCFOk7YhQ== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 1/5] btrfs: rename some variables at try_release_extent_mapping() Date: Wed, 17 Apr 2024 12:03:31 +0100 Message-Id: <4a210b101a5bf6fc2a1dac4e9e66d612ce50d0f2.1713302470.git.fdmanana@suse.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana Rename the following variables: 1) "btrfs_inode" to "inode", because it's shorter to type and clear, and we don't have a vfs inode here as well, so there's no confusion; 2) "tree" to "io_tree", to be clear which tree we are dealing with, since we use 2 different trees in the function; 3) "map" to "extent_tree" since "map" gives the idea we are dealing with an extent map for example, but we are dealing with the inode's extent tree (the tree which stores extent maps). These also makes the next patches simpler. Signed-off-by: Filipe Manana Reviewed-by: Johannes Thumshirn --- fs/btrfs/extent_io.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 7b10f47d8f83..6438c3e74756 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2398,9 +2398,9 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) struct extent_map *em; u64 start = page_offset(page); u64 end = start + PAGE_SIZE - 1; - struct btrfs_inode *btrfs_inode = page_to_inode(page); - struct extent_io_tree *tree = &btrfs_inode->io_tree; - struct extent_map_tree *map = &btrfs_inode->extent_tree; + struct btrfs_inode *inode = page_to_inode(page); + struct extent_io_tree *io_tree = &inode->io_tree; + struct extent_map_tree *extent_tree = &inode->extent_tree; if (gfpflags_allow_blocking(mask) && page->mapping->host->i_size > SZ_16M) { @@ -2410,19 +2410,19 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) u64 cur_gen; len = end - start + 1; - write_lock(&map->lock); - em = lookup_extent_mapping(map, start, len); + write_lock(&extent_tree->lock); + em = lookup_extent_mapping(extent_tree, start, len); if (!em) { - write_unlock(&map->lock); + write_unlock(&extent_tree->lock); break; } if ((em->flags & EXTENT_FLAG_PINNED) || em->start != start) { - write_unlock(&map->lock); + write_unlock(&extent_tree->lock); free_extent_map(em); break; } - if (test_range_bit_exists(tree, em->start, + if (test_range_bit_exists(io_tree, em->start, extent_map_end(em) - 1, EXTENT_LOCKED)) goto next; @@ -2442,7 +2442,7 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) * Otherwise don't remove it, we could be racing with an * ongoing fast fsync that could miss the new extent. */ - fs_info = btrfs_inode->root->fs_info; + fs_info = inode->root->fs_info; spin_lock(&fs_info->trans_lock); cur_gen = fs_info->generation; spin_unlock(&fs_info->trans_lock); @@ -2457,12 +2457,12 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) * hurts the fsync performance for workloads with a data * size that exceeds or is close to the system's memory). */ - remove_extent_mapping(btrfs_inode, em); + remove_extent_mapping(inode, em); /* once for the rb tree */ free_extent_map(em); next: start = extent_map_end(em); - write_unlock(&map->lock); + write_unlock(&extent_tree->lock); /* once for us */ free_extent_map(em); @@ -2470,7 +2470,7 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) cond_resched(); /* Allow large-extent preemption. */ } } - return try_release_extent_state(tree, page, mask); + return try_release_extent_state(io_tree, page, mask); } struct btrfs_fiemap_entry { From patchwork Wed Apr 17 11:03:32 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13633211 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A88013D2A7 for ; Wed, 17 Apr 2024 11:03:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351830; cv=none; b=BITICYa9LQIZwk6Qyc21FI6+Ag2i2/45KR5Z2jPn1/Onx4RglKn0Mk7U6wOZWYye6uM3cVMo9Y2r27Eya/Bcqdd7rSlg3x/Jq/UTQpX2r8lAVEBWN1lsQev4zHBuOEPzY6AZ74DVuC3qiJaqOZYfwtRJ0qLQ8O7cJEJ2+9u8jSA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351830; c=relaxed/simple; bh=JqZ4OjqU7g7yKQOq+QVsLg3cq3E9F9Ko2piwpu/wL+E=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=gXgcx74+onDNmfxxQRoUk1ow+/FvlaTsulYkwrK5H65bQZxvzLiqhP9C+C8e6n9m/+GVJpqfM4tqFsUhWetf6UJmS7QI5T2KLJwRE8CrVFOa89b3vVNM3/PKTqma1iUgLVD461er1QE0a+MTJigq/8kHm7064uCHqr0fDxbF300= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nAbadJyd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nAbadJyd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30B96C32783 for ; Wed, 17 Apr 2024 11:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713351829; bh=JqZ4OjqU7g7yKQOq+QVsLg3cq3E9F9Ko2piwpu/wL+E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nAbadJydzEJmSqng5QJtwFkwOWM+2yx2ARD8/iQ9rzoTgrASkLX3AKZowWtOyPZWo G9rMTSNZvNFXtLl9QFpsUc7L7z48NJNrN5AQ8L72DHMEZJ2eCZKUIVeG+L13EDUxOZ jpgH5I5RKvc8jGAw/HHEKXDL5/O8N07Al0aEXKSepsV5glVaIANnvlBTqnclwGOoAt oQRZtVhs5LutfEjFiQyvA5pse6nAyJIELLqQsrncVCLacvV/l0sKOVKOyWdrgWWnus E6IpUyDGk8AkjfHu7VfQlfclUf9opQRE08C0YWSxZXPy2iVAq5k/Wi/crHIXtRsSMA lZPIQKRFdYcpw== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 2/5] btrfs: use btrfs_get_fs_generation() at try_release_extent_mapping() Date: Wed, 17 Apr 2024 12:03:32 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana Nowadays we have the btrfs_get_fs_generation() to get the current generation of the filesystem, so there's no need anymore to lock the transaction spinlock to read it. Signed-off-by: Filipe Manana Reviewed-by: Johannes Thumshirn --- fs/btrfs/extent_io.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 6438c3e74756..f689c53553e3 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2406,8 +2406,7 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) page->mapping->host->i_size > SZ_16M) { u64 len; while (start <= end) { - struct btrfs_fs_info *fs_info; - u64 cur_gen; + const u64 cur_gen = btrfs_get_fs_generation(inode->root->fs_info); len = end - start + 1; write_lock(&extent_tree->lock); @@ -2442,10 +2441,6 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) * Otherwise don't remove it, we could be racing with an * ongoing fast fsync that could miss the new extent. */ - fs_info = inode->root->fs_info; - spin_lock(&fs_info->trans_lock); - cur_gen = fs_info->generation; - spin_unlock(&fs_info->trans_lock); if (em->generation >= cur_gen) goto next; remove_em: From patchwork Wed Apr 17 11:03:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13633212 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F2C2F13D8AE for ; Wed, 17 Apr 2024 11:03:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351832; cv=none; b=WD3xnd96WX5LXV2i4j9HiN0waC2f72pGkB0jUi5TEORfd8zbXjr8uv3bUr9hTrkElYHkgnEYYcoapuPQmc+ACSNoAYX6Is2TTvhTEOP8+g9wjHAYrMbgrESu96DMga4cRdXwbJXRgHhPTIVRQUD9r0yYTLq0d6vT61ZGrUsjsmc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351832; c=relaxed/simple; bh=1fhIyN2mqG+pYHEEhMcJF7Xs9wjC3Uiwlev1Usgn9tM=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=OaX3DlynPkEa8KEc2CC3TsrvqknA7wv+ZZBnKIfGzwxW10zcqq4bI9/3xTfILWs/S2wPSeN2bGIi1WH4tGfEUqfRA78C0YVk5yvHiWJVPstTaWayYE/9lNCQwBlQ5BFPN8+lXxKeuk7l6sju/z1JQsJBIsyhKhWdOY5Ej+BVC/U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vAibfdNW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vAibfdNW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0791BC4AF07 for ; Wed, 17 Apr 2024 11:03:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713351831; bh=1fhIyN2mqG+pYHEEhMcJF7Xs9wjC3Uiwlev1Usgn9tM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vAibfdNWY7SI+b2EQCKaO7tCkeSmpbiEQ3o44adZmKNL9MvE2DWcwOYjPAhlD+fV7 XB91ICwkgbRqZ2htgPGtqHonYaJDVQ8UQ8NQtKmwNG4xBJU39uf0EzCCwIgQjvSESP ySrs8z6E8HttZC/DG/xZOq3s4VZu8EdI7Z5d1DRoA8pz77kHxMBh3ugMIpx/cQhSDz r7FbAmQrm0AJg3Y7z8TZC6T+R4L/8wHh2+cFNt/ds2CepFXxN2avEEVPqdTA3BNSse sCONYnlWBeOjm5hC4jGR6EasvglN/gj+oT//eI4px84CC7wyLSXJgqOPVP6SegeHjT tjbYbFhd+mdtw== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 3/5] btrfs: remove i_size restriction at try_release_extent_mapping() Date: Wed, 17 Apr 2024 12:03:33 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana Currently we don't attempt to release extent maps if the inode has an i_size that is not greater than 16M. This condition was added way back in 2008 by commit 70dec8079d78 ("Btrfs: extent_io and extent_state optimizations"), without any explanation about it. A quick chat with Chris on slack revealed that the goal was probably to release the extent maps for small files only when closing the inode. This however can be harmful in case we have tons of such files being kept open for very long periods of time, since we will consume more and more pages for extent maps. So remove the condition. Signed-off-by: Filipe Manana Reviewed-by: Johannes Thumshirn --- fs/btrfs/extent_io.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index f689c53553e3..ff9132b897e3 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2402,8 +2402,7 @@ int try_release_extent_mapping(struct page *page, gfp_t mask) struct extent_io_tree *io_tree = &inode->io_tree; struct extent_map_tree *extent_tree = &inode->extent_tree; - if (gfpflags_allow_blocking(mask) && - page->mapping->host->i_size > SZ_16M) { + if (gfpflags_allow_blocking(mask)) { u64 len; while (start <= end) { const u64 cur_gen = btrfs_get_fs_generation(inode->root->fs_info); From patchwork Wed Apr 17 11:03:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13633213 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AF1F13E41B for ; Wed, 17 Apr 2024 11:03:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351833; cv=none; b=aAc79N/ujUOsFKwOW3YXHqvvE1gq74O3AbloU/wyAiJz3DIoGs8z8g8Yem7BRAALpBZXAiONbMfU7Le/5/sN7f+ISWeo/Gizh2x4/F4HYGvYNx88fQKh4Q8kGZ+Np9DMez1PyBXfO12jaIG1IM5ldmxs3NIfp5QQFzZh2fc3Mwk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351833; c=relaxed/simple; bh=+2rJfZ+rgSP1rvZsl6ZHDHYCz31rfo8CeBtXIr0kjRA=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=PO1M/1ZioNegnXQscRKKvml7JHj93jq9OgFt1kND8FA4uDoKiflnu1tNWtIivUDic8q+F1O2Lus3XxF4SAw/DyYWUbukyj7A0zO01q//TktTavcY5U5UP3YQ/M7ChmYxrTVY8lu/aVReECNpEti2dah2ZkbmBriomJ9M85YFXZY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uPHdSVkZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uPHdSVkZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35DE1C32781 for ; Wed, 17 Apr 2024 11:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713351832; bh=+2rJfZ+rgSP1rvZsl6ZHDHYCz31rfo8CeBtXIr0kjRA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=uPHdSVkZsshjQjdF4WVJl4sy7o0AYLrZS+gNX/aw4OBYdOUog3yXQ063RhDvI8L5k W4vsHp9yjPqX/BQC3AT2se3M4oy2Pu2bz4nByiTgRmtzjK4Oqjhns/NYlURseNzOGg gUC9djOI+tJoFcPm3W2bn6pi1K6yJAeMG73MN7upZ64gzzm8jTrMVBjGUq3Jf9L2ks cRTP2IVMkijDiZPT3PIj/cxMKUwzLYfniNy8464fPrJfSoieFEtuNvfftoADfHvir6 RLCQ8FASbBSR/t2OB9NmTpr/13l/n8s2m1fuskqwUK4lOq8FsDHNXS+aMHF8vBDKQU Dv16bnfvkkK5Q== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 4/5] btrfs: be better releasing extent maps at try_release_extent_mapping() Date: Wed, 17 Apr 2024 12:03:34 +0100 Message-Id: <225a3fc5fdbe804cf40dabe27f0d8a9f07f9a1d3.1713302470.git.fdmanana@suse.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana At try_release_extent_mapping(), called during the release folio callback (btrfs_release_folio() callchain), we don't release any extent maps in the range if the gfp flags don't allow blocking. This behaviour is exaggerated because: 1) Both searching for extent maps and removing them are not blocking operations. The only thing that it is the cond_resched() call at the end of the loop that searches for and removes extent maps; 2) We currently only operate on a single page, so for the case where block size matches the page size, we can only have one extent map, and for the case where the block size is smaller than the page size, we can have at most 16 extent maps. So it's very unlikely the cond_resched() call will ever block even in the block size smaller than page size scenario. So instead of not removing any extent maps at all in case the gfp glags don't allow blocking, keep removing extent maps while we don't need to reschedule. This makes it safe for the subpage case and for a future where we can process folios with a size larger than a page. Signed-off-by: Filipe Manana Reviewed-by: Johannes Thumshirn --- fs/btrfs/extent_io.c | 120 ++++++++++++++++++++++--------------------- 1 file changed, 61 insertions(+), 59 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index ff9132b897e3..2230e6b6ba95 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2395,73 +2395,75 @@ static int try_release_extent_state(struct extent_io_tree *tree, */ int try_release_extent_mapping(struct page *page, gfp_t mask) { - struct extent_map *em; u64 start = page_offset(page); u64 end = start + PAGE_SIZE - 1; struct btrfs_inode *inode = page_to_inode(page); struct extent_io_tree *io_tree = &inode->io_tree; - struct extent_map_tree *extent_tree = &inode->extent_tree; - - if (gfpflags_allow_blocking(mask)) { - u64 len; - while (start <= end) { - const u64 cur_gen = btrfs_get_fs_generation(inode->root->fs_info); - - len = end - start + 1; - write_lock(&extent_tree->lock); - em = lookup_extent_mapping(extent_tree, start, len); - if (!em) { - write_unlock(&extent_tree->lock); - break; - } - if ((em->flags & EXTENT_FLAG_PINNED) || - em->start != start) { - write_unlock(&extent_tree->lock); - free_extent_map(em); - break; - } - if (test_range_bit_exists(io_tree, em->start, - extent_map_end(em) - 1, - EXTENT_LOCKED)) - goto next; - /* - * If it's not in the list of modified extents, used - * by a fast fsync, we can remove it. If it's being - * logged we can safely remove it since fsync took an - * extra reference on the em. - */ - if (list_empty(&em->list) || - (em->flags & EXTENT_FLAG_LOGGING)) - goto remove_em; - /* - * If it's in the list of modified extents, remove it - * only if its generation is older then the current one, - * in which case we don't need it for a fast fsync. - * Otherwise don't remove it, we could be racing with an - * ongoing fast fsync that could miss the new extent. - */ - if (em->generation >= cur_gen) - goto next; -remove_em: - /* - * We only remove extent maps that are not in the list of - * modified extents or that are in the list but with a - * generation lower then the current generation, so there - * is no need to set the full fsync flag on the inode (it - * hurts the fsync performance for workloads with a data - * size that exceeds or is close to the system's memory). - */ - remove_extent_mapping(inode, em); - /* once for the rb tree */ + + while (start <= end) { + const u64 cur_gen = btrfs_get_fs_generation(inode->root->fs_info); + const u64 len = end - start + 1; + struct extent_map_tree *extent_tree = &inode->extent_tree; + struct extent_map *em; + + write_lock(&extent_tree->lock); + em = lookup_extent_mapping(extent_tree, start, len); + if (!em) { + write_unlock(&extent_tree->lock); + break; + } + if ((em->flags & EXTENT_FLAG_PINNED) || em->start != start) { + write_unlock(&extent_tree->lock); free_extent_map(em); + break; + } + if (test_range_bit_exists(io_tree, em->start, + extent_map_end(em) - 1, EXTENT_LOCKED)) + goto next; + /* + * If it's not in the list of modified extents, used by a fast + * fsync, we can remove it. If it's being logged we can safely + * remove it since fsync took an extra reference on the em. + */ + if (list_empty(&em->list) || (em->flags & EXTENT_FLAG_LOGGING)) + goto remove_em; + /* + * If it's in the list of modified extents, remove it only if + * its generation is older then the current one, in which case + * we don't need it for a fast fsync. Otherwise don't remove it, + * we could be racing with an ongoing fast fsync that could miss + * the new extent. + */ + if (em->generation >= cur_gen) + goto next; +remove_em: + /* + * We only remove extent maps that are not in the list of + * modified extents or that are in the list but with a + * generation lower then the current generation, so there is no + * need to set the full fsync flag on the inode (it hurts the + * fsync performance for workloads with a data size that exceeds + * or is close to the system's memory). + */ + remove_extent_mapping(inode, em); + /* Once for the inode's extent map tree. */ + free_extent_map(em); next: - start = extent_map_end(em); - write_unlock(&extent_tree->lock); + start = extent_map_end(em); + write_unlock(&extent_tree->lock); - /* once for us */ - free_extent_map(em); + /* Once for us, for the lookup_extent_mapping() reference. */ + free_extent_map(em); + + if (need_resched()) { + /* + * If we need to resched but we can't block just exit + * and leave any remaining extent maps. + */ + if (!gfpflags_allow_blocking(mask)) + break; - cond_resched(); /* Allow large-extent preemption. */ + cond_resched(); } } return try_release_extent_state(io_tree, page, mask); From patchwork Wed Apr 17 11:03:35 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13633214 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE89D13F012 for ; Wed, 17 Apr 2024 11:03:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351833; cv=none; b=YjeeEmvWgwrtc0GqHmaJ68TZ0uUsbQxRcRkiaywJOxHkZFTPqV10SDroOt3hF1KAQp/1H3hHhgRdRSy4aJ+Tpqsn4cXO5ZEse/h7Rm1dytYh+gcNnT7XInAFfY3qoyyNYGoV6ttZhdFchJAayKPcnFgb8zcX9ryOIVXVR0XYBuc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713351833; c=relaxed/simple; bh=H7/sxcxSK6j8daBWi4xAOIhZBvV5eZ9TMczjMwTb8gg=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=cADEB9R7z6z99/4QkWvlcUbi/Qg2nncVeWpmsRUVG+Bbl2Yp/4OFzt8qNzswl1pbwTrI1NZnkoqeQ6xtMKbypnaJ3eHUMIjbZACQA5YKP1837kEsaum38NfK4iJ9yH3o4SyemwWvdtxnf2UyHJEbs4MQCV223dwl6Dhun9JCeFI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I1GGwzgs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I1GGwzgs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C9EFC2BD10 for ; Wed, 17 Apr 2024 11:03:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713351833; bh=H7/sxcxSK6j8daBWi4xAOIhZBvV5eZ9TMczjMwTb8gg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I1GGwzgsLSrsutggS8rhJwlbeftzttXSXWeJQfQRMF8S39EE38nvfMh4eMS7xRIhQ +0/fJlWvGSDWsvGT7YjbWSEixeVLOXL0sBYU7zvDbVNgHlEXo36RWVumBcj0aHwiPt Fxsra6YypneJXz2q4JNwMeSkNAxKD3du+6IP8mqbEZgka/4a+72iblGuwIDTVk6HAe 8xFwFs4nhpS99NpGXrQmr1/gq9fcK2c0jbJhxrtLn6rFeqVccAxlYnENXErM44OcTj 1NzUsEB4cAoATIcTqCUqS3wJI7KCGUpN8KEQIVTQuWqXhdUzECWLZAlEzSc7yp5FFH V74plLd8JBivw== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 5/5] btrfs: make try_release_extent_mapping() return a bool Date: Wed, 17 Apr 2024 12:03:35 +0100 Message-Id: <49e09cbdb4c54f8b383bf7f21a1678cfbdc12e86.1713302470.git.fdmanana@suse.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana Currently try_release_extent_mapping() as an int return type, but we use it as a boolean. Its only caller, the release folio callback, also returns a boolean which corresponds to try_release_extent_mapping()'s return value. So change its return value type to bool as well as its helper try_release_extent_state(). Signed-off-by: Filipe Manana Reviewed-by: Johannes Thumshirn --- fs/btrfs/extent_io.c | 17 +++++++++-------- fs/btrfs/extent_io.h | 2 +- fs/btrfs/inode.c | 7 +++---- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 2230e6b6ba95..a9f9f5abdf53 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2355,19 +2355,20 @@ int extent_invalidate_folio(struct extent_io_tree *tree, * are locked or under IO and drops the related state bits if it is safe * to drop the page. */ -static int try_release_extent_state(struct extent_io_tree *tree, +static bool try_release_extent_state(struct extent_io_tree *tree, struct page *page, gfp_t mask) { u64 start = page_offset(page); u64 end = start + PAGE_SIZE - 1; - int ret = 1; + bool ret; if (test_range_bit_exists(tree, start, end, EXTENT_LOCKED)) { - ret = 0; + ret = false; } else { u32 clear_bits = ~(EXTENT_LOCKED | EXTENT_NODATASUM | EXTENT_DELALLOC_NEW | EXTENT_CTLBITS | EXTENT_QGROUP_RESERVED); + int ret2; /* * At this point we can safely clear everything except the @@ -2375,15 +2376,15 @@ static int try_release_extent_state(struct extent_io_tree *tree, * The delalloc new bit will be cleared by ordered extent * completion. */ - ret = __clear_extent_bit(tree, start, end, clear_bits, NULL, NULL); + ret2 = __clear_extent_bit(tree, start, end, clear_bits, NULL, NULL); /* if clear_extent_bit failed for enomem reasons, * we can't allow the release to continue. */ - if (ret < 0) - ret = 0; + if (ret2 < 0) + ret = false; else - ret = 1; + ret = true; } return ret; } @@ -2393,7 +2394,7 @@ static int try_release_extent_state(struct extent_io_tree *tree, * in the range corresponding to the page, both state records and extent * map records are removed */ -int try_release_extent_mapping(struct page *page, gfp_t mask) +bool try_release_extent_mapping(struct page *page, gfp_t mask) { u64 start = page_offset(page); u64 end = start + PAGE_SIZE - 1; diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h index c81a9b546c9f..f38397765e90 100644 --- a/fs/btrfs/extent_io.h +++ b/fs/btrfs/extent_io.h @@ -230,7 +230,7 @@ static inline void extent_changeset_free(struct extent_changeset *changeset) kfree(changeset); } -int try_release_extent_mapping(struct page *page, gfp_t mask); +bool try_release_extent_mapping(struct page *page, gfp_t mask); int try_release_extent_buffer(struct page *page); int btrfs_read_folio(struct file *file, struct folio *folio); diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 30893f12c850..622600f5f313 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -7902,13 +7902,12 @@ static void wait_subpage_spinlock(struct page *page) static bool __btrfs_release_folio(struct folio *folio, gfp_t gfp_flags) { - int ret = try_release_extent_mapping(&folio->page, gfp_flags); - - if (ret == 1) { + if (try_release_extent_mapping(&folio->page, gfp_flags)) { wait_subpage_spinlock(&folio->page); clear_page_extent_mapped(&folio->page); + return true; } - return ret; + return false; } static bool btrfs_release_folio(struct folio *folio, gfp_t gfp_flags)