Why is NFSv4 so slow?

[Rick Macklem]

> 
> Do you (or will you soon) have some patches I/we could test? I'm
> willing to try anything to avoid mounting ten or so subdirectories in
> each of my mount points.
> 

Attached is a small patch for the only difference I can spot in the read
code between the regular and experimental NFS client.

I have asked jhb@ to try and do some testing, to see if he can reproduce
it. If he does reproduce it, maybe he can figure out what is going on.
(I don't think I'll have any further patches to try, unless he spots
something.)

> > One thing you could try is building a kernel without SMP enabled
> > and see if that helps? (I only have single core hardware, so I won't
> > see any SMP races.) If that helps, I can compare the regular vs
> > experimental client for smp locking in the read stuff.
> 
> I can try disabling SMP too. Should that really matter, if you're not
> even pegging one CPU? The locks shouldn't have *that* much overhead...
> 
> -- Rick C. Petty
>
If running UMP fixes the problem, it is most likely a missing lock that
allows a race to put things in a weird state. But for these things, it
is often something I'd never expect that turns out to be the culprit.

rick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfsclbio.patch
Type: text/x-patch
Size: 470 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100904/a632c8ab/nfsclbio.bin