Re: [PATCH] Btrfs: throttle delayed refs better

On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik [off-list ref] wrote:

On 02/05/2014 02:30 PM, Johannes Hirte wrote:

quoted

On Wed, 5 Feb 2014 14:00:57 -0500
Josef Bacik [off-list ref] wrote:

quoted

On 02/05/2014 12:34 PM, Johannes Hirte wrote:

quoted

On Wed, 5 Feb 2014 10:49:15 -0500
Josef Bacik [off-list ref] wrote:

quoted

Ok none of those make sense which makes me think it may be the
ktime bits, instead of un-applying the whole patch could you just
comment out the parts

           ktime_t start = ktime_get();

and

           if (actual_count > 0) {
                   u64 runtime =
ktime_to_ns(ktime_sub(ktime_get(), start)); u64 avg;

                   /*
                    * We weigh the current average higher than
our current runtime
                    * to avoid large swings in the average.
                    */
                   spin_lock(&delayed_refs->lock);
                   avg = fs_info->avg_delayed_ref_runtime * 3 +
runtime; avg = div64_u64(avg, 4);
                   fs_info->avg_delayed_ref_runtime = avg;
                   spin_unlock(&delayed_refs->lock);
           }

in __btrfs_run_delayed_refs and see if that makes the problem
stop? If it does will you try chris's for-linus branch to see if
it still reproduces there?  Maybe some patch changed ktime_get()
in -rc1 that is causing issues and we're just now exposing it.
Thanks,

With the ktime bits disabled, I wasn't able to reproduce the
problem anymore. With Chris' for-linus branch it took longer but
still appeared.

Ok can you send your .config, maybe there's some weird time bug
being exposed.  What kind of CPU do you have?  Thanks,

Josef

It's a Core i5-540M, dualcore + hyperthreading

Ok while I'm doing this can you change 
btrfs_should_throttle_delayed_refs to _always_ return 1, still with
all the ktime stuff commented out, and see if that causes the problem
to happen?  Thanks,

Yes it does. Same behavior as without ktime stuff commented out.