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/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:27 EST