summaryrefslogtreecommitdiffstats
path: root/mm/highmem.c
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2013-06-21 08:58:19 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2013-06-29 12:57:45 +0400
commit3999e49364193f7dbbba66e2be655fe91ba1fced (patch)
tree5971637ac3b15d5d72797d4050ee35216b9fede1 /mm/highmem.c
parent48f74186546cd5929397856eab209ebcb5692d11 (diff)
downloadlinux-3999e49364193f7dbbba66e2be655fe91ba1fced.tar.gz
linux-3999e49364193f7dbbba66e2be655fe91ba1fced.tar.bz2
linux-3999e49364193f7dbbba66e2be655fe91ba1fced.zip
locks: add a new "lm_owner_key" lock operation
Currently, the hashing that the locking code uses to add these values to the blocked_hash is simply calculated using fl_owner field. That's valid in most cases except for server-side lockd, which validates the owner of a lock based on fl_owner and fl_pid. In the case where you have a small number of NFS clients doing a lot of locking between different processes, you could end up with all the blocked requests sitting in a very small number of hash buckets. Add a new lm_owner_key operation to the lock_manager_operations that will generate an unsigned long to use as the key in the hashtable. That function is only implemented for server-side lockd, and simply XORs the fl_owner and fl_pid. Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'mm/highmem.c')
0 files changed, 0 insertions, 0 deletions