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 >> >> >> 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
