kernel nfs code: decreasing speed since 2.1.131ac5

Oskar Pearson (oskar@linux.org.za)
Wed, 30 Dec 1998 06:28:45 +0200


Hi

I am trying to get a fast NFS server going here. I started fiddling around
with the knfsd code with 2.1.131ac5 - running bonnie and other tests.

It seems that things have slowed down since I first started. The local-disk-io
speeds have increased (bonnie results included here, just for people's
interest).

NFS speeds, however, have dropped slightly. I am not sure why this is (and it's
6am, so I am not going to go crawling throught patches right now - and even
if I did, I would certainly just get everything wrong! :)

2.1.131ac5 seems pretty happy (though I haven't compared it to older versions
Between there and 2.2.0pre1ac1 sequential output has dropped by about
300K per second.

Sequential per char input has dropped by something near 1 megabyte per second
and sequential block input has by even more. Number of random seeks has also
dropped a little.

Alan has said that the new nfs code sits on the buffer cache. Could the recent
tunings of this have changed things? It's possible that the nfs code hasn't
changed significantly enough to do this (unless someone has plugged in broken
readahead support?).

Info: Two ultra-wide, ultra fast (40MB/s) disks raid-0d together. 256Mb
ram, 1gig bonnie files. I have used the default nfs mount options - no
fiddling with read/write sizes or anything.

LOCAL DISK ACCESS:
Local disk access seems to be pretty stable - it is getting better with time.

-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU

2.1.131, ac5
run1 1024 8680 84.7 24806 55.8 6891 33.0 7592 79.4 21968 37.9 105.1 2.8
run2 1024 9029 87.7 25019 56.2 6933 33.2 7647 79.2 22082 38.0 103.3 2.7

2.2.0 pre1 vanilla
run1 1024 9068 88.3 25035 56.4 6925 32.6 7621 79.3 20562 36.2 109.1 2.8
run2 1024 8913 86.9 25015 56.3 7021 33.8 7656 79.1 20705 37.2 108.0 2.7

2.2.0 pre1, ac1
run1 1024 9056 88.0 24915 55.6 6827 32.5 7624 79.3 22073 39.0 108.1 2.6
run2 1024 9012 87.7 24920 55.6 6825 32.8 7619 79.2 22087 39.1 110.0 3.2
run3 1024 9140 88.9 24880 55.8 6777 32.6 7624 79.4 22142 38.7 107.8 2.6

ACROSS KERNEL-NFS:

All tests are localhost mounts. Performance seems to have dropped between
kernel 2.1.131 and kernel 2.2.0

-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU

2.0.36, nfs-server-2.2beta40:
1024 2269 32.5 2936 16.7 1358 17.5 2505 39.6 3273 21.3 39.0 3.2

2.1.131, ac5
run1 1024 5193 49.2 7122 21.5 4092 20.5 3444 38.1 4628 9.9 49.1 1.9
run2 1024 5134 48.9 7226 22.5 4101 20.5 4231 46.8 6581 14.2 54.6 2.0
(When I applied the readahead patch that came with knfsd, performance dropped)
2.1.131, ac5, readahead patch
run1 1024 4455 43.1 6247 19.1 2762 12.6 1119 12.8 1145 7.2 30.1 0.8

(check out how the per-char sequential output and random seek values fall
here - compared to 2.1.131ac5 WITHOUT the readahead patch. Block throughput
is close to the old user-level nfs patch)
2.1.132
run1 1024 5190 48.9 7012 19.2 4069 19.0 2175 24.0 2555 5.1 37.9 1.3
1024 5205 49.4 7011 19.2 4106 19.3 2257 24.7 2646 5.3 38.0 1.2

2.2.0 pre1
run1 1024 5218 48.9 7000 20.1 4051 19.3 2420 26.5 2872 6.0 39.9 1.2
run2 1024 5200 49.2 6989 20.0 4054 19.3 2214 24.6 2601 5.5 37.2 1.2

The ac1 changes seem to slow block stuff down further - at least they
speed the random seeks and sequential input a little

2.2.0 pre1, ac1
run1 1024 4941 56.3 6859 20.2 3934 19.6 2671 29.7 3233 7.0 44.5 1.5
run2 1024 4862 45.4 6741 20.1 3901 20.3 2314 25.8 2695 6.4 38.0 1.4

-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU

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