Re: Cleanup patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux