On Sun, 13 Jul 2014 22:39:34 -0400 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > I'm certainly happy to try beating on it a bit hard, and can see if I can get > > access to an 80-core machine that I had a brief play with a while back and do > > some more testing there. > > As I said, it's not required for merging, but would definitely be an > interesting test in order to see how it affects NFS performance in > general. If you have access to a good test setup with an interesting > workload, then I'd love to see the results of a "before vs after" > comparison using nfsometer. > I managed to get access to a big machine for a while so I ran nfsometer. Seemed to run quite well but there are a couple of little issues I might mention separately. I didn't let iozone_direct complete because it was taking *forever*. The results are at http://neil.brown.name/nfsometer_results/ I cannot find a good summary page... I tested three kernels on the same 80-core (160 if you count hyperthreads) machine: A v3.12 that was installed, a vanilla 3.16-rc5, and the 3.16-rc5 with my patches. Some numbers look good, some look strange. Can you (or someone) have a look? I also ran my compile-test and graphed some results, which I attach. This is just 3 kernels, 3.16-rc5 with and without my patches. I tested both v3 and v4. I ran the "make" command with "-j" values from 4 to 80 in steps of 4. The runs lots of compiles of a trivial file but has a very long list of include directories which are all on NFS and all empty. So there are lots of attempts to open non-existent files, and the non-existence is cached early. As you see, with the "-rcu" very performance is enormously better. Without my patches, more concurrency means worse performance. Thanks, NeilBrown
Attachment:
make-times.png
Description: PNG image
Attachment:
signature.asc
Description: PGP signature
