On Sun, Nov 16, 2014 at 12:30 AM, Dušan Čolić <dusanc@xxxxxxxxx> wrote: > On Sun, Nov 16, 2014 at 12:30 AM, Edward Shishkin > <edward.shishkin@xxxxxxxxx> wrote: >> >> On 11/16/2014 12:06 AM, Dušan Čolić wrote: >>> >>> These are results from bisecting of R4 slowdown with ccreg40 plugin >> > > Brainfart after hours of bisecting. I meant reg40 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 >>> Here are the more bisected results: 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-rc1 3m13.643s 0m2.884s 1m30.482s 2.6.21-rc2 3m10.054s 0m2.904s 1m30.106s 2.6.21-rc3 7m39.374s 0m2.848s 1m29.570s 2.6.21-rc4 7m37.928s 0m2.904s 1m30.778s 2.6.21 7m52.960s 0m2.992s 1m28.326s 2.6.21 7m35.929s 0m3.044s 1m34.738s 2.6.22-2 6m57.991s 0m2.852s 1m28.258s Obviously something happened between rc2 and rc3 >>> >>> 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...... >> >>
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-rc1 3m13.643s 0m2.884s 1m30.482s 2.6.21-rc2 3m10.054s 0m2.904s 1m30.106s 2.6.21-rc3 7m39.374s 0m2.848s 1m29.570s 2.6.21-rc4 7m37.928s 0m2.904s 1m30.778s 2.6.21 7m52.960s 0m2.992s 1m28.326s 2.6.21 7m35.929s 0m3.044s 1m34.738s 2.6.22-2 6m57.991s 0m2.852s 1m28.258s
