On Wed, 5 Feb 2014 10:49:15 -0500
Josef Bacik <jba...@fb.com> wrote:
> 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.
regards,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
