Re: Cleanup patches

[Edward Shishkin <edward.shishkin@gmail.com>]

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@gmail.com> 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@gmail.com>
>> wrote:
>>> On 11/15/07, Dushan Tcholich <dusanc@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html