I'm a little confused of what avg_delayed_ref_runtime means.
In __btrfs_run_delayed_refs(), avg_delayed_ref_runtime is set to the
runtime of all delayed refs processed in current transaction commit.
However, in btrfs_should_throttle_delayed_refs(), we based on the
following condition to decide
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 10:38 AM, 钱凯 wrote:
I'm a little confused of what avg_delayed_ref_runtime means.
In __btrfs_run_delayed_refs(), avg_delayed_ref_runtime is set to
the runtime of all delayed refs processed in current transaction
commit. However, in
On Fri, 14 Feb 2014 14:29:35 -0500
Josef Bacik jba...@fb.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/14/2014 02:25 PM, Johannes Hirte wrote:
On Thu, 6 Feb 2014 16:19:46 -0500 Josef Bacik jba...@fb.com
wrote:
Ok so I thought I reproduced the problem but I just
On Thu, 6 Feb 2014 16:19:46 -0500
Josef Bacik jba...@fb.com wrote:
Ok so I thought I reproduced the problem but I just reproduced a
different problem. Please undo any changes you've made and apply
this patch and reproduce and then provide me with any debug output
that gets spit out. I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/14/2014 02:25 PM, Johannes Hirte wrote:
On Thu, 6 Feb 2014 16:19:46 -0500 Josef Bacik jba...@fb.com
wrote:
Ok so I thought I reproduced the problem but I just reproduced a
different problem. Please undo any changes you've made and
On 02/05/2014 05:57 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 16:46:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 04:42 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb
On 02/05/2014 05:57 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 16:46:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 04:42 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb
On Tue, 4 Feb 2014 09:12:54 -0500
Josef Bacik jba...@fb.com wrote:
Hrm I was hoping that was going to be more helpful. Can you get perf
record -ag and then perf report while it's at full cpu and get the
first 3 or 4 things with their traces?
Here it comes:
#
# captured on: Wed Feb
On 02/05/2014 03:14 AM, Johannes Hirte wrote:
On Tue, 4 Feb 2014 09:12:54 -0500
Josef Bacik jba...@fb.com wrote:
Hrm I was hoping that was going to be more helpful. Can you get perf
record -ag and then perf report while it's at full cpu and get the
first 3 or 4 things with their traces?
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
On 02/05/2014 12:34 PM, Johannes Hirte wrote:
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 =
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:00:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 12:34 PM, Johannes Hirte wrote:
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
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:00:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 12:34 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 10:49:15 -0500
Josef Bacik
On 02/05/2014 04:42 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:00:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 12:34 PM, Johannes Hirte wrote:
On Wed, 5 Feb
On 02/05/2014 04:42 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:00:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 12:34 PM, Johannes Hirte wrote:
On Wed, 5 Feb
On Wed, 5 Feb 2014 16:46:57 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 04:42 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:36:39 -0500
Josef Bacik jba...@fb.com wrote:
On 02/05/2014 02:30 PM, Johannes Hirte wrote:
On Wed, 5 Feb 2014 14:00:57 -0500
Josef Bacik
On 02/03/2014 05:53 PM, Johannes Hirte wrote:
On Mon, 3 Feb 2014 16:08:08 -0500
Josef Bacik jba...@fb.com wrote:
On 02/03/2014 01:28 PM, Johannes Hirte wrote:
On Thu, 23 Jan 2014 13:07:52 -0500
Josef Bacik jba...@fb.com wrote:
On one of our gluster clusters we noticed some pretty big lag
On Thu, 23 Jan 2014 13:07:52 -0500
Josef Bacik jba...@fb.com wrote:
On one of our gluster clusters we noticed some pretty big lag
spikes. This turned out to be because our transaction commit was
taking like 3 minutes to complete. This is because we have like 30
gigs of metadata, so our
On 02/03/2014 01:28 PM, Johannes Hirte wrote:
On Thu, 23 Jan 2014 13:07:52 -0500
Josef Bacik jba...@fb.com wrote:
On one of our gluster clusters we noticed some pretty big lag
spikes. This turned out to be because our transaction commit was
taking like 3 minutes to complete. This is because
On Mon, 3 Feb 2014 16:08:08 -0500
Josef Bacik jba...@fb.com wrote:
On 02/03/2014 01:28 PM, Johannes Hirte wrote:
On Thu, 23 Jan 2014 13:07:52 -0500
Josef Bacik jba...@fb.com wrote:
On one of our gluster clusters we noticed some pretty big lag
spikes. This turned out to be because
On 01/24/2014 02:34 AM, Liu Bo wrote:
On Thu, Jan 23, 2014 at 01:07:52PM -0500, Josef Bacik wrote:
On one of our gluster clusters we noticed some pretty big lag spikes. This
turned out to be because our transaction commit was taking like 3 minutes to
complete. This is because we have like 30
On one of our gluster clusters we noticed some pretty big lag spikes. This
turned out to be because our transaction commit was taking like 3 minutes to
complete. This is because we have like 30 gigs of metadata, so our global
reserve would end up being the max which is like 512 mb. So our
On Thu, Jan 23, 2014 at 01:07:52PM -0500, Josef Bacik wrote:
On one of our gluster clusters we noticed some pretty big lag spikes. This
turned out to be because our transaction commit was taking like 3 minutes to
complete. This is because we have like 30 gigs of metadata, so our global
23 matches
Mail list logo
