[lkml]   [2003]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] concurrent block allocation for ext3
>>>>> Andreas Dilger (AD) writes:

AD> Any ideas on how much this improves the performance? What sort
AD> of tests were you running? We could improve things a bit further
AD> by having separate per-group locks for the update of the group
AD> descriptor info, and only lazily update the superblock at statfs
AD> and unmount time (with a suitable feature flag so e2fsck can fix
AD> this up at recovery time), but you seem to have gotten the
AD> majority of the parallelism from this fix.

I'm trying to measure improvement.

The tests were:

1) on big fs (1GB)
lots of processes (up to 50) creating, removing directories and files +
untaring kernel and make -j4 bzImage +
dd if=/dev/zero of=/mnt/dump.file bs=1M count=8000; rm -f /mnt/dump.file

2) on small fs (64MB)
20 processes create and remove lots of files and directories

in fact, I catched dozens of debug messages about set_bit collision. Then
I fscked fs to be sure all is ok.

>> @@ -214,11 +213,13 @@ block + i); BUFFER_TRACE(bitmap_bh, "bit
>> already cleared"); } else { +
>> spin_lock(&EXT3_SB(sb)->s_alloc_lock); dquot_freed_blocks++;
gdp-> bg_free_blocks_count =
>> cpu_to_le16(le16_to_cpu(gdp->bg_free_blocks_count)+1);
es-> s_free_blocks_count =
>> cpu_to_le32(le32_to_cpu(es->s_free_blocks_count)+1); +
>> spin_unlock(&EXT3_SB(sb)->s_alloc_lock);

AD> One minor nit is that you left an ext3_error() for the "bit
AD> already cleared" case just above this patch hunk.

hmm. whats wrong with it?

with best regards, Alex

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.048 / U:2.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site