On Fri, Aug 31, 2018 at 10:52:55AM +0300, Nikolay Borisov wrote: > > > On 30.08.2018 20:41, Josef Bacik wrote: > > From: Josef Bacik <jba...@fb.com> > > > > We use this number to figure out how many delayed refs to run, but > > __btrfs_run_delayed_refs really only checks every time we need a new > > delayed ref head, so we always run at least one ref head completely no > > matter what the number of items on it. So instead track only the ref > > heads added by this trans handle and adjust the counting appropriately > > in __btrfs_run_delayed_refs. > > > > Signed-off-by: Josef Bacik <jba...@fb.com> > > --- > > fs/btrfs/delayed-ref.c | 3 --- > > fs/btrfs/extent-tree.c | 5 +---- > > 2 files changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c > > index 3a9e4ac21794..27f7dd4e3d52 100644 > > --- a/fs/btrfs/delayed-ref.c > > +++ b/fs/btrfs/delayed-ref.c > > @@ -234,8 +234,6 @@ static inline void drop_delayed_ref(struct > > btrfs_trans_handle *trans, > > ref->in_tree = 0; > > btrfs_put_delayed_ref(ref); > > atomic_dec(&delayed_refs->num_entries); > > - if (trans->delayed_ref_updates) > > - trans->delayed_ref_updates--; > > There was feedback on this particular hunk and you've completely ignored > it, that's not nice: > > https://www.spinics.net/lists/linux-btrfs/msg80514.html
I just missed it in the last go around (as is the case for the other ones). I'm not sure what part is confusing, we only want delayed_ref_updates to be how many delayed ref heads there are, which is what this patch is changing. I could probably split this between these two changes and the count changing below since they are slightly different things, I'll do that. Thanks, Josef
