Re: Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB

[Nick Piggin]

On Wednesday 04 February 2009 03:12:45 Chris Mason wrote:
> On Tue, 2009-02-03 at 13:11 +1100, Nick Piggin wrote:

> > The interesting thing is why is this causing such a slowdown. If there is
> > only a single main file active in the workload, then I don't see why this
> > patch should make such a big difference. In either case, wouldn't pdflush
> > come back and just start writing out from the start of the file anyway?
>
> Perhaps the difference is that without the patch, pdflush will return
> after running congestion_wait()?  This would give bdb and iozone a
> chance to fill in more pages, and increases the chances we'll do
> sequential IO.

That's a possible explanation. I'll do some iozone runs and see if I can
work out what's going on. If we can distill the "goodness" of the previous
offset-wrap behaviour without reverting to make writeout more offset
dependent, that would be nice -- it might even benefit other cases that
weren't previously hitting the offset wrap case.

Worst case, if we can't come up with something simple and obvious for 2.6.29,
we can restore the old behaviour until we can come up with something better.

Thanks,
Nick

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/