Test 1 Test 2
user sys elapsed worst 2nd user sys elapsed worst 2nd comments
2.0.36 27.69 7.70 2:37.27 9.73 6.88 28.97 10.21 17:30.68 76.37 75.11 poor
28.32 7.33 0:43.87 3.36 2.32
27.52 7.40 0:43.08 3.42 2.22
2.2.5 28.13 6.80 2:50.52 8.00 7.19 29.44 8.70 13:21.34 61.29 64.95 fine
28.64 6.61 1:47.39 7.91 6.77
28.55 6.40 1:48.49 7.88 7.11
2.2.5arca12 27.99 6.77 1:24.68 14.93 9.38 30.13 6.91 4:13.60 14.08 13.09 very poor
28.98 6.69 1:19.67 14.12 9.56
28.18 6.77 1:18.99 13.89 9.39
2.2.6 28.20 6.70 2:47.06 7.47 6.87 31.73 8.92 14:41.84 16.57 16.53 fine
28.92 6.17 1:46.01 7.97 6.62
28.69 6.39 1:47.77 7.81 6.76
2.2.6arca1 28.66 7.73 1:24.43 13.85 9.06 30.07 9.62 10:45.50 65.61 45.63 fine
29.15 7.82 1:15.55 13.38 8.74
28.37 7.85 1:12.91 13.33 7.24
2.2.6a2* 28.04 7.24 0:42.24 2.82 2.10 29.89 7.33 1:30.70 6.09 4.34 excellent
28.44 7.06 0:42.37 2.82 2.10
28.02 6.96 0:41.94 2.79 2.09
27.88 7.23 0:42.39 2.80 2.09**
* - 2.2.6a2 = 2.2.6andrea2.
** - run again directly from a reboot because I couldn't believe the #s!
Smokin! 2.2.6andrea2 was so incredibly fast that I didn't really
have much time to test it interactively, but it was great. Netscape
came up in under a minute.
To stress it on my 32mb machine, I tried out the 100,000 record
interactive test (test2) both with gdbm_sync & without gdbm_sync:
This was with netscape blowing up sizably:
hjstein 479 5.2 26.9 25736 8360 1 S 23:40 0:36 /usr/lib/netscape/netscape-communicator -install
hjstein 488 0.0 0.0 12776 0 1 SW 23:40 0:00 (netscape-commun)
With gdbm_sync (interactive test, 100,000 records):
user sys elapsed worst 2nd
91.16 24.42 10:51.33 51.41 46.82
87.56 21.85 3:12.71 13.88 9.72
Now I started periodically getting sizable pauses, along with
significant mouse freezes (~5-10 seconds). I would have expected them
to occur during heavy I/O, but surprisingly, the disk is pretty busy
most of the time (I can hear it), and during most of the
pauses/freezes, the disk is silent! System time is way up and
utilization is way down. Maybe it's locked up while organizing memory
for the fsync call?
The second time I guess I just wasn't hitting the system as hard
interactively. I barely noticed it running. It's still pretty
amazing - the #s are competitive with the other kernels doing half as
many records.
Without gdbm_sync (interactive test):
user sys elapsed worst 2nd
88.50 24.90 17:38.55 97.38 74.78
It didn't have big pauses while the test was running, but it ran much
slower! The system *was* sluggish and did have lots of annoying
little pauses, more so than with gdbm_sync. Either gdbm_sync is doing
what I want it to do, or I'm hitting edge conditions - maybe we start
seeing serious degredation when sufficient memory is in use and I'm
not always hitting that level. Maybe writes to disk are getting
cached for too long - they fill up memory & then the system starts
writing wildly? The silent freezes are weird, though.
The plots of time for each 1000 records tell a story too, but I don't
want to include a 758 line uuencoded file here.
Andrea - maybe you'd like to reboot with 32 mb & try running a 100,000
record test with gdbm_sync on and lots of netscape windows, maybe
gnuplot, an emacs & some xterms to see if you can pin down the
freezes? Or maybe on your 128mb machine you'll need a 500,000 record
test to really stress it. I wouldn't be surprised if this is as good
as it gets, but you never know...
-- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/