> On Jan 6, 2023, at 1:00 AM, Wang Yugui <wangyugui@xxxxxxxxxxxx> wrote: > > Hi, > >> From: Chuck Lever <chuck.lever@xxxxxxxxxx> >> >> While we were converting the nfs4_file hashtable to use the kernel's >> resizable hashtable data structure, Neil Brown observed that the >> list variant (rhltable) would be better for managing nfsd_file items >> as well. The nfsd_file hash table will contain multiple entries for >> the same inode -- these should be kept together on a list. And, it >> could be possible for exotic or malicious client behavior to cause >> the hash table to resize itself on every insertion. >> >> A nice simplification is that rhltable_lookup() can return a list >> that contains only nfsd_file items that match a given inode, which >> enables us to eliminate specialized hash table helper functions and >> use the default functions provided by the rhashtable implementation). >> >> Since we are now storing nfsd_file items for the same inode on a >> single list, that effectively reduces the number of hash entries >> that have to be tracked in the hash table. The mininum bucket count >> is therefore lowered. > > some bench result such as fstests generic/531 maybe useful. Sure. I don't expect there will be much change, but one never knows. > And this patch conflict with another patch: > (v3) [PATCH] nfsd: fix handling of cached open files in nfsd4_open codepath Yes, this is known to conflict with patches that are now in flight. I'll rebase once those are merged. -- Chuck Lever
