Re: Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux