On 11/16/2014 09:29 AM, Dušan Čolić wrote:
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
And some new relevant ones:
2.6.29 2m57.027s 0m3.096s 1m33.266s
3.17.2 2m34. 1m20.
3.17 is cropped because I copied it by hand as network didn't work
with old userspace.
Is this issue closed now?
Thank you for your work!
TBH, I thought that the performance issue introduced in 2.6.21-rc3
still takes place in modern kernels..
Edward.
Have a nice day
Dushan
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......
--
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
