Date: Wed, 24 May 2017 20:40:00 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: NFS client performance degradation when SMP enabled Message-ID: <YTXPR01MB018936F6F86EFE57801E0AB7DDFE0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
Without boring you with too much detail, I have been doing development/test= ing of pNFS stuff (mostly server side) on a 1 year old kernel (Apr. 12, 2016). When I recently carried the code across to a recent kernel, everything seem= ed to work, but performance was much slower. After some fiddling around, it appears to be on the NFS client side and not= hing in the NFS client code seemed to be causing it. (RPC counts were almost exactly th= e same, for example. I tried reverting r316532 and disabling vfs.nfs.use_buf_pager.= Neither made a significant difference.) I made most of the performance degradation go away by disabling SMP on the = client. Here's some elapsed times for kernel builds with everything the same except= for which kernel and SMP enabled/disabled (amd64 client machine). 1 year old kernel, SMP enabled - 100minutes recent kernel, SMP disabled - 113minutes recent kernel, SMP enabled - 148minutes (The builds were all of the same kernel sources. When I say "1 year old" vs= "recent" I am referring to which kernel was booted for the test run.) All I can think of is that some change in the last year has resulted in an = increase in something like interrupt latency or context switch latency that has caused = this? Anyone have an idea what this might be caused by or any tunables to fool wi= th beyond disabling SMP (which I suspect won't be a popular answer to "how to = fix slow NFS";-). I haven't yet tried fiddling with interrupt moderation on the net interface= , but the tests all used the same settings. rick=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB018936F6F86EFE57801E0AB7DDFE0>