Hi Ted: On Wed, Jan 7, 2009 at 12:47 PM, Theodore Tso <tytso@xxxxxxx> wrote: > On Wed, Jan 07, 2009 at 11:29:11AM -0800, Curt Wohlgemuth wrote: >> >> I ran both iozone and compilebench on the following filesystems, using a >> 2.6.26-based kernel, with most ext4 patches applied. This is on a x86 based >> 4-core system, with a separate disk for these runs. > > Curt, thanks for doing these test runs. One interesting thing to note > is that even though ext3 was running with barriers disabled, and ext4 > was running with barriers enabled, ext4 still showed consistently > better resuls. (Or was this on an LVM/dm setup where barriers were > getting disabled?) Nope. Barriers were enabled for both ext4 versions below. > A couple of things to note. If you were testing Frank's patches, I > made one additional optimization to his patch, which removed the > orphaned inode handling. This wasn't necessary if you're running > without the journal, I'm not sure if this would be measurable in your > benchmarks, since the inodes that would be getting modified were > probably going to be dirtied and require writeback anyway, but you > might get sightly better numbers with the version of the patch I > ultimately pushed to Linus. I see the change you pushed; I'll integrate this and see if the numbers look any different. > The other thing to note is that in Compilebench's read_tree, ext2 and > ext3 are scoring better than ext4. This is probably related to ext4's > changes in its block/inode allocation hueristics, which is something > that we probably should look at as part of tuning exercises. The > brtfs.boxacle.net benchmarks showed something similar, which I also > would attribute to changes in ext4's allocation policies. Can you enlighten me as to what aspect of block allocation might be involved in the slowdown here? Which block group these allocations are made from? Or something more low-level than that? Thanks, Curt -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
