Re: [PATCH 04/35] btrfs: only track ref_heads in delayed_ref_updates

Josef Bacik
2018-08-31T18:18:30Z

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 <jbacik@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 <jbacik@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