On 10/31/2011 03:27 AM, Tao Ma wrote:
On 10/31/2011 06:15 PM, Theodore Tso wrote:
On Oct 27, 2011, at 11:31 PM, Tao Ma wrote:
Forget to say, if we increase the extent length to be cluster, there are
also a good side effect. ;) Current bigalloc has a severe performance
regression in the following test case:
mount -t ext4 /dev/sdb1 /mnt/ext4
cp linux-3.0.tar.gz /mnt/ext4
cd /mnt/ext4
tar zxvf linux-3.0.tar.gz
umount /mnt/ext4
I've been traveling, so I haven't had a chance to test this, but it makes no sense that changing the encoding fro the extent length would change the performance of the forced writeback caused by amount. There may be a performance bug that we should fix, or may have been fixed by accident with the extent encoding change.
Have you investigated why this got better when you changed the meaning of the extent length field? It makes no sense that such a format change would have such an impact….
OK, so let me explain why the big cluster length works.
In the new bigalloc case if chunk size=64k, and with the linux-3.0
source, every file will be allocated a chunk, but they aren't contiguous
if we only write the 1st 4k bytes. In this case, writeback and the block
layer below can't merge all the requests sent by ext4. And in our test
case, the total io will be around 20000. While with the cluster size, we
have to zero the whole cluster. From the upper point of view. we have to
write more bytes. But from the block layer, the write is contiguous and
it can merge them to be a big one. In our test, it will only do around
2000 ios. So it helps the test case.
Am I missing something but you cannot zero the entire cluster because
block_write_full_page() drops pages past i_size.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5693486bad2bc2ac585a2c24f7e2f3964b478df9
--
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
