On Wed, Jan 31, 2018 at 07:34:24PM -0600, Jeremy Linton wrote: > On 01/31/2018 09:49 AM, J. Bruce Fields wrote: > > In the kernel compile case there's probably also a lot of re-opening and > > re-reading files too? NFSv4 is chattier there too. Read delegations > > should help compensate, but we need to improve the heuristics that > > decide when they're given out. > > The main kernel include files get repeatedly hammered, despite them in > theory being in cache, IIRC. So yes, if the concurrent (re)open path is even > slightly slower its going to hurt a lot. > > > All that aside I can't think what would explain that big a difference > > (45 minutes vs. 5). It might be interesting to figure out what > > happened. > > I had already spent more than my time allotted looking in the wrong > direction at the filesystem/RAID (did turn off intellipark though) by the > time I discovered the nfsv3/v4 perf delta. Its been sitting way down on the > "things to look into" list for a long time now. I'm still using it as a NFS > server so at some point I can take another look if the problem persists. OK, understood. Well, if you ever want to take another look at the v4 issue--I've been meaning to rework the delegation heuristics. Assuming you're on a recent kernel, I could give you some experimental (but probably not too risky) kernel patches if you didn't mind keeping notes on the results. I'll probably get around to it eventually on my own, but it'd probably happen sooner with a collaborator. But the difference you saw was so drastic, there may have just been some unrelated NFSv4 bug..... --b. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
