On Mon, Jun 23, 2014 at 09:56:45AM -0400, Jeff Layton wrote: > Thanks for taking a look. The big problem with breaking this set up is > that it will likely result in at least some performance regression in > the interim. We're adding more granular locking inside of the > coarse-grained client_mutex, which is likely to mean at least some > slowdown until the client_mutex is removed. Maybe that's worth it > though. That's why I didn't dare to ask for splitting the lock breakup, but rather the surrounding fixes and logic changes. But yes, if that's not doable either we'll have to bite the bullet. > > - there is some confusion of NFSd vs nfsd in the subsystem prefixes. > > While it seems odd and against the usual naming NFSd seems to be > > the common one for nfs patches. > > > > I tend to prefer "nfsd", but ok -- "NFSd" it is. I'd prefer nfsd as well, but in Rome do as the Romans do, so.. -- 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
