On Tue, Jul 01, 2014 at 04:13:17PM -0400, Jeff Layton wrote: > On Tue, 1 Jul 2014 16:01:35 -0400 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > On Tue, Jul 01, 2014 at 02:46:31PM -0400, Jeff Layton wrote: > > > Ok, I haven't tested that yet, but I did put together a f20 machine on > > > bare metal to act as a server. Here are some results from a test that > > > forks 128 child processes and has each one create and close 1024 files. > > > Client is 3.14.8-200.fc20.x86_64 and using NFSv4.1: > > > > > > With a stock Fedora kernel on the server running 3.14.8-200.fc20.x86_64: > > > > > > $ time sudo ./opentest -n 128 -l 1024 /mnt/palma > > > > > > real 59m5.022s > > > user 0m1.401s > > > sys 0m17.561s > > > > > > > > > ...with the patched kernel 3.16.0-rc2.jlayton.1+ (basically Bruce's > > > for-3.17 branch with the rest of my patches piled on): > > > > > > $ time sudo ./opentest -n 128 -l 1024 /mnt/palma > > > > > > real 4m19.060s > > > user 0m1.259s > > > sys 0m13.059s > > > > > > ...so around a factor of 13x speedup on parallel creates. Again, this > > > is not a terribly scientific benchmark, but it does suggest that this > > > patchset helps immensely. > > > > Neat-o. > > > > It might also be interesting to compare with NFSv3? > > > > I wonder what a first good test of the smp scalability would be. > > > > --b. > > Yeah, it is neato. And just to be sure that it wasn't some other random > change between 3.14 and 3.16, I popped off all of my patches, rebuilt > nfsd.ko and reran the test with everything else the same: > > $ time sudo ./opentest -n 128 -l 1024 /mnt/palma > > real 58m50.564s > user 0m1.513s > sys 0m18.963s > > ...so it really does appear that these changes make the difference. Yes, and that number sounds about right: that's about 27ms per create, which sounds like about the right number for latency of a create on a normal hard drive? (No idea how to think about the patched case.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
