Hi Trond-
Calling nlm_lookup_host() during each NLM operation is a lot of overhead.
The nlm_lookup_host() function grabs the nlm_host_mutex, serializing
NLM operations and generating extra CPU invalidations on SMP systems.
The nlm_lookup_host() function can also trigger nlm_host garbage
collection, and reorders the global nlm_host chain after every successful
nlm_host lookup, resulting in extraneous memory write traffic.
In addition, nlmclnt_proc() pokes around in the NFS inode and in the
NFS client's rpc_xprt struct, both of which are layering violations that
we can and should avoid.
The new architecture pins an nlm_host structure to each NFS client
superblock that has the "lock" mount option set. The client passes
in the pinned nlm_host structure during each call to nlmclnt_proc(). NFS
client unmount processing "puts" the nlm_host so it can be garbage-
collected later.
By pinning an nlm_host for each mount point, we trade the overhead of
looking up or creating a fresh nlm_host struct during every NLM procedure
call for a little extra memory space utilization.
Please consider these patches for 2.6.25.
Sidebar: there are only a few remaining references to the internals of
NFS inodes in the client-side NLM code. The only references I found are
related to extracting or comparing the inode's file handle via NFS_FH().
One is in nlmclnt_grant(); the other is in nlmclnt_setlockargs().
--
corporate: <chuck dot lever at oracle dot com>