Journal Filesystem Comparison on Netbench
Quoted 3 lines · Hans Reiser
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
Quoted 6 lines · Andi Kleen
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_forwardandreiserfs_in_journal
...
journaled blocks set also, to quickly skip them for the common case.
I'm very interested in the way you did profiling. Did you compile the kernel with profiling options (gprof ?) ? If so, where the profiling information file is saved ?
Thanks
-Manu
Quoted 9 lines · Emmanuel Varagnat
Quoted 6 lines · Andi Kleen
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_forwardandreiserfs_in_journal
...
journaled blocks set also, to quickly skip them for the common case.
Quoted 3 lines
I'm very interested in the way you did profiling. Did you compile the kernel with profiling options (gprof ?) ? If so, where the profiling information file is saved ?
I did not do any profiling in this case; I just read an existing log. If you want to do profiling yourself you could use the simple builtin statistical profiler: boot with profile=2 on the command line and read the log at anytime using the readprofile command. Other ways are documented on the lse homepage http://lse.sourceforge.net
-Andi
Quoted 6 lines · Andi Kleen
I did not do any profiling in this case; I just read an existing log. If you want to do profiling yourself you could use the simple builtin statistical profiler: boot with profile=2 on the command line and read the log at anytime using the readprofile command. Other ways are documented on the lse homepage http://lse.sourceforge.net
Thanks for all.
-Manu
Quoted 15 lines · Andi Kleen
Quoted 9 lines · Emmanuel Varagnat
Quoted 6 lines · Andi Kleen
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_forwardandreiserfs_in_journal
...
journaled blocks set also, to quickly skip them for the common case.Quoted 3 lines
I'm very interested in the way you did profiling. Did you compile the kernel with profiling options (gprof ?) ? If so, where the profiling information file is saved ?
Quoted 5 lines
I did not do any profiling in this case; I just read an existing log. If you want to do profiling yourself you could use the simple builtin statistical profiler: boot with profile=2 on the command line and read the log at anytime using the readprofile command. Other ways are documented on the lse homepage http://lse.sourceforge.net
The profiles I provided were with SGI's kernprof 0.9.2. I chose ACG, which does have a lot of overhead (cg_record_arc and mcount), but also provides a lot of information. I have a separate kernel for each filesystem and each filesystem+profle_patch (10 kernels). No modules were used so that all profiles have no 'unknown kernel' functions. Each profile was taken for 60 seconds, starting at 90 seconds into the test. All profiles were taken on the 44 client test.
Andrew Theurer