Messages in this thread | | | Subject | Re: Journal Filesystem Comparison on Netbench | From | Andi Kleen <> | Date | 28 Aug 2001 08:51:32 +0200 |
| |
Hans Reiser <reiser@namesys.com> writes:
> That said, it does not surprise me that our locking is coarser than other > filesystems, and we will be fixing that in version 4. Unfortunately we don't > have the hardware to replicate your results.
It does not really look like a locking problem. If you look at the profiling logs it is pretty clear that the problem is the algorithm used in bitmap.c:find_forward. find_forward and reiserfs_in_journal (called by find_forward) are by most the biggest CPU users in file system space, and reiserfs_in_journal is called over 30 million times, far more often than any other function. On looking at it it is pretty clear why it is slow; the algorithm is just stupid. It also runs under the BKL, which explains the long locking times. Fix that function and it'll look much better. i.e. one way would be to keep a shadow map of all bitmaps that has all journaled blocks set also, to quickly skip them for the common case.
-Andi
- 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/
| |