Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH] concurrent block allocation for ext3 | From | Alex Tomas <> | Date | 10 Mar 2003 19:33:44 +0300 |
| |
>>>>> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |