On Sun, Nov 16, 2014 at 2:28 AM, Dušan Čolić <dusanc@xxxxxxxxx> wrote: > 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 > And in attachment are all patches from that range. krshina3 linux # git log --pretty=oneline v2.6.21-rc2...v2.6.21-rc3 | cat > /mnt/media/diffpatches Any ideas what would be good to revert? >>>> >>>> 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:
diffpatches
Description: Binary data
