On Tue, Oct 25, 2011 at 04:22:48PM -0400, Josef Bacik wrote:
> On Tue, Oct 25, 2011 at 04:15:45PM -0400, Chris Mason wrote:
> > On Tue, Oct 25, 2011 at 11:05:12AM -0400, Josef Bacik wrote:
> > > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote:
> > > >
> > > > Attached is a perf-report. I have included the whole report, so that
> > > > you can see the difference between the good and the bad
> > > > btrfs-endio-wri.
> > > >
> > >
> > > We also shouldn't be running run_ordered_operations, man this is screwed
> > > up,
> > > thanks so much for this, I should be able to nail this down pretty easily.
> > > Thanks,
> >
> > Looks like we're getting there from reserve_metadata_bytes when we join
> > the transaction?
> >
>
> We don't do reservations in the endio stuff, we assume you've reserved all the
> space you need in delalloc, plus we would have seen reserve_metadata_bytes in
> the trace. Though it does look like perf is lying to us in at least one case
> sicne btrfs_alloc_logged_file_extent is only called from log replay and not
> during normal runtime, so it definitely shouldn't be showing up. Thanks,
Whoops, I should have read that num_items > 0 check harder.
btrfs_end_transaction is doing it by setting ->blocked = 1
if (lock && !atomic_read(&root->fs_info->open_ioctl_trans) &&
should_end_transaction(trans, root)) {
trans->transaction->blocked = 1;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
smp_wmb();
}
if (lock && cur_trans->blocked && !cur_trans->in_commit) {
^^^^^^^^^^^^^^^^^^^
if (throttle) {
/*
* We may race with somebody else here so end up having
* to call end_transaction on ourselves again, so inc
* our use_count.
*/
trans->use_count++;
return btrfs_commit_transaction(trans, root);
} else {
wake_up_process(info->transaction_kthread);
}
}
perf is definitely lying a little bit about the trace ;)
-chris
--
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
