These are results from bisecting of R4 slowdown with ccreg40 plugin 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......
Attachment:
config
Description: Binary data
Attachment:
prepare_copy.sh
Description: Bourne shell script
Attachment:
ncopy.sh
Description: Bourne shell script
