[Btrfs-devel] [PATCH] delay commit if work is done while we're asleep

[Chris Mason]

On Thu, 9 Aug 2007 16:10:36 -0400
Josef Bacik <jwhiter at redhat.com> wrote:

> On Thu, Aug 09, 2007 at 11:56:31AM -0400, Josef Bacik wrote:
> > On Thu, Aug 09, 2007 at 11:44:17AM -0400, Chris Mason wrote:
> > > On Thu, 9 Aug 2007 11:34:14 -0400
> > > Josef Bacik <jwhiter at redhat.com> wrote:
> > > 
> > > > On Thu, Aug 09, 2007 at 11:20:51AM -0400, Chris Mason wrote:
> > > > > On Thu, 9 Aug 2007 11:07:39 -0400
> > > 
> > > I welcome all patches ;)  Didn't want to ask you for another
> > > rewrite for a small change, but I'd actually love to see numbers
> > > for how much it helps/hurts your runs.  I'm starting a long test
> > > here of unrelated changes, so I won't be testing this out until
> > > later today.
> > > 
> > > BTW, which revisions are you testing against?
> > > 
> > 
> > Ok I'll rework the patch and re-run my tests and include my numbers
> > next time around.  What do you mean which revisions?  I pulled down
> > what was in mercurial this morning and ran tests against that, then
> > did my patch and re-ran my tests, if thats what you are asking.
> > Thanks much,
> > 
> 
> Hmm well my numbers are sucking now with the modifications made to my
> original patch, tho they are pretty good mulithreaded.  What I'm
> going to do is finish out my fsync work (right now i'm working on
> tracking the last trans_handle that modified the inode and seeing if
> its already been committed) and then do a good round of testing and
> make sure there is a good performance increase, as it stands now with
> just my "wait for more writers" patch if anything its going to hurt
> performance in a single threaded instance.
> 
> Josef
> 
> PS.  When I say my numbers suck I mean that with my patch i get about
> 58 files/sec and without it I get 61, so not too bad but not good.

This isn't horribly surprising, we're trading latency for throughput.
You can probably improve the single writer case by kicking the btrfs
work queue more often to clean up the trees left over by old commits.

So, I wouldn't be too worried about that kind of degradation, most of
the apps that do lots of fsyncs do it with lots of threads.

-chris