On 11/16/2014 12:06 AM, Dušan Čolić wrote:
These are results from bisecting of R4 slowdown with ccreg40 plugin
Hmm.. Are you sure?
2.6.10 doesn't know about ccreg...
with config and scripts I used, first double run is to see dispersion
of consecutive tests:
Reiser4 patch Real User System
2.6.10-2 2m46.785s 0m3.214s 1m45.286s
2.6.10-2 2m52.700s 0m3.198s 1m43.361s
2.6.16-5 3m32.694s 0m2.900s 1m34.698s
2.6.19-4 3m19.672s 0m3.120s 1m33.234s
2.6.20 3m9.582s 0m3.164s 1m28.830s
2.6.21 7m52.960s 0m2.992s 1m28.326s
2.6.22-2 6m57.991s 0m2.852s 1m28.258s
Have a nice day
Dushan
On Fri, Oct 24, 2014 at 11:17 PM, Dušan Čolić <dusanc@xxxxxxxxx> wrote:
OK after 7 years, can't believe how long ago it was, I decided to dig up
some ancient hw and to try again to do this bisect.
Questions:
1. Would it still be useful?
2. Any other tests that I can do on those old kernels that can be of value?
3. What would be best bisect range? Oldest and newest kernel?
On Nov 14, 2007 11:39 PM, "Edward Shishkin" <edward.shishkin@xxxxxxxxx>
wrote:
On 11/15/07, Dushan Tcholich <dusanc@xxxxxxxxx> wrote:
...
Well. There is a problem: starting from some point, performance of
reiser4 is substantially dropped for unknown reasons. As I remember,
there were a lot of complaints about it. Also I have made a brief
test not so long ago (copy of linux source tree located in ramfs to
reiser4 partition): yeah, it is 3 times worse then it ought to be,
"vmstat 2" reports low bo-activity (something like 10000 blocks/s,
instead of usual ~30000).
It would be nice to find a changeset which kills performance.
Would you please look at this? It is non-trivial task, so every
result would be ok (say, to know the first kernel in -mm series
with slow reiser4).
Hints:
1. The problem is in (default) unix-file plugin (nobody maintained
this for a long of time), so compression should be disabled.
2. I guess it should be something like bisecting.
3. I think that the problem appeared in ~2.6.17-mmXX kernel when
vs sent vfs patches with batch_write methods, and then Andrew
Morton evicted them because of some problems. However,
I might be wrong here!
If you could give me an easy way to benchmark (guide me by hand), I
could try to bisect it.
It would be easier if -mm could be bisected using git.
But my / is on r4+cc, so I don't know how could I do it? Maybe on
other machine?
Yes! Compression announced 15 March 2007, and it may happen
that some kernel you will need to boot are not support your "/".
So for bisecting you need the following:
1. a machine with >= 512M RAM and "/" formatted with some fs
supported by old kernels.
2. a spare partition.
3. enable ramfs (it seems it is enabled by default in most distros).
4. put a tarball-to-copy in some working directory (I had
linux-2.6.9.tar.gz)
Note, that some old -mm kernels are not compilable/bootable
(if so, pull the "hotfixes" patches from akpm's directory on kernel.org)
5. edit the attached patches in accordance with your configurations
6. build and boot the testing kernel with reiser4 debug disabled
(I think no needs to boot in single mode, or discard kde, etc..)
7. run "vmstat 2"
8. run ./prepare_copy.sh && ./ncopy on another console
I have the following:
real 6m27.970s
user 0m2.116s
sys 1m4.972s
God, it is fairly bad results: On my machine real time should be
something like 2m20......
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
