FAILED: patch "[PATCH] btrfs: use correct compare function of dirty_metadata_bytes" failed to apply to 4.9-stable tree
Subsystems (2)
[email protected]
maintainerThe patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
d814a49198eafa6163698bdd93961302f3a877a4Mon Sep 17 00:00:00 2001
From: Ethan Lien <[email protected]>
Date: Mon, 2 Jul 2018 15:44:58 +0800
Subject: [PATCH] btrfs: use correct compare function of dirty_metadata_bytes
We use customized, nodesize batch value to update dirty_metadata_bytes. We should also use batch version of compare function or we will easily goto fast path and get false result from percpu_counter_compare().
fs/btrfs/disk-io.c +6 -4
@@ -959,8 +959,9 @@ static int btree_writepages(struct address_space *mapping, fs_info =BTRFS_I (mapping->host)->root->fs_info;/* this is a bit racy, but that's ok */ - ret =percpu_counter_compare (&fs_info->dirty_metadata_bytes, -BTRFS_DIRTY_METADATA_THRESH ); + ret =__percpu_counter_compare (&fs_info->dirty_metadata_bytes, +BTRFS_DIRTY_METADATA_THRESH , + fs_info->dirty_metadata_batch);if (ret <0 )return 0 ; }
@@ -4134,8 +4135,9 @@ static void __btrfs_btree_balance_dirty(struct btrfs_fs_info *fs_info,if (flush_delayed)btrfs_balance_delayed_items (fs_info); - ret =percpu_counter_compare (&fs_info->dirty_metadata_bytes, -BTRFS_DIRTY_METADATA_THRESH ); + ret =__percpu_counter_compare (&fs_info->dirty_metadata_bytes, +BTRFS_DIRTY_METADATA_THRESH , + fs_info->dirty_metadata_batch);if (ret >0 ) {balance_dirty_pages_ratelimited (fs_info->btree_inode->i_mapping); }
PATCH 1/1 btrfs: use correct compare function of dirty_metadata_bytes
From: Ethan Lien <[email protected]>
We use customized, nodesize batch value to update dirty_metadata_bytes. We should also use batch version of compare function or we will easily goto fast path and get false result from percpu_counter_compare().
---
Here is a 4.9.y backport of upstream commit:d814a49198eafa6163698bdd93961302f3a877a4
fs/btrfs/disk-io.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
fs/btrfs/disk-io.c +6 -4
@@ -1096,8 +1096,9 @@ static int btree_writepages(struct address_space *mapping, fs_info =BTRFS_I (mapping->host)->root->fs_info;/* this is a bit racy, but that's ok */ - ret =percpu_counter_compare (&fs_info->dirty_metadata_bytes, -BTRFS_DIRTY_METADATA_THRESH ); + ret =__percpu_counter_compare (&fs_info->dirty_metadata_bytes, +BTRFS_DIRTY_METADATA_THRESH , + fs_info->dirty_metadata_batch);if (ret <0 )return 0 ; }
@@ -4107,8 +4108,9 @@ static void __btrfs_btree_balance_dirty(struct btrfs_root *root,if (flush_delayed)btrfs_balance_delayed_items (root); - ret =percpu_counter_compare (&root->fs_info->dirty_metadata_bytes, -BTRFS_DIRTY_METADATA_THRESH ); + ret =__percpu_counter_compare (&root->fs_info->dirty_metadata_bytes, +BTRFS_DIRTY_METADATA_THRESH , + root->fs_info->dirty_metadata_batch);if (ret >0 ) {balance_dirty_pages_ratelimited ( root->fs_info->btree_inode->i_mapping);
Signature · 1 line
2.7.4
Re: [PATCH] btrfs: use correct compare function of dirty_metadata_bytes
Quoted 13 lines · Nikolay Borisov
From: Ethan Lien <[email protected]>
We use customized, nodesize batch value to update
dirty_metadata_bytes. We should also use batch version of compare function or we will easily goto fast path and get false result frompercpu_counter_compare().Fixes e2d845211eda ("Btrfs: use percpu counter for dirty metadata count")CC [email protected] # 4.4+Signed-off-by Ethan Lien <[email protected]>Reviewed-by Nikolay Borisov <[email protected]>Signed-off-by David Sterba <[email protected]>[nb: Rebased on 4.9.y]Signed-off-by Nikolay Borisov <[email protected]>
Quoted 4 lines
---
Here is a 4.9.y backport of upstream commit:
d814a49198eafa6163698bdd93961302f3a877a4
Please put this information to the changelog itself as the first line:
commit d814a49198eafa6163698bdd93961302f3a877a4 upstream.