Excerpts from Mitch Harder's message of 2011-08-02 10:35:54 -0400: > I'm running into a significant slowdown in Btrfs (> 10x slower than > normal) that appears to be due to some issue between how Btrfs is > allocating memory, and how the kernel is expecting Btrfs to allocate > memory. > > The problem does seem to be somewhat hardware specific. I can > reproduce on two of my computers (an older AMD Athlon(tm) XP 2600+ > with PATA, and a newer ACER Aspire netbook with an Atom CPU). My > Core2Duo computer with SATA seems unaffected by this slowdown. > > I've replicated this on 2.6.38, 2.6.39, and 3.0 kernels. The > following information was all obtained running on a 3.0 kernel merged > with the latest 'for-linus' branch of Chris' git repo. I've also > tested on ext4 (no slow down encountered) to make sure the issue > wasn't completely unrelated to Btrfs.
Just to double check, what was the top commit of for-linus when you did this? The tracing shows that you're spending your time in mmap'd readahead. So one of three things is happening: 1) The VM is favoring our metadata over data pages for the git packed file 2) We're reading ahead too aggressively, or not aggressively enough 3) The git pack file is somehow more fragmented, and this is making the read ahead much less effective. The very first thing I'd check is to make sure the .git repo between the slow machines and the fast machines are identical. Git does a lot of packing behind the scenes, and so an older repo that isn't freshly cloned is going to be slower than a new repo. -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
