Re: [PATCH 2/3] NFSD: Add infrastructure for tracking persistent SCSI registration keys

[Chuck Lever <chuck.lever@oracle.com>]

On 12/18/25 4:34 AM, Christoph Hellwig wrote:
> On Mon, Dec 15, 2025 at 10:13:34AM -0800, Dai Ngo wrote:
>> +
>> +int
>> +nfsd4_scsi_pr_init_hashtbl(struct nfsd_net *nn)
>> +{
>> +	int ix;
>> +
>> +	nn->client_pr_record_hashtbl = kmalloc_array(CLIENT_HASH_SIZE,
>> +					sizeof(struct list_head),
>> +					GFP_KERNEL);
>> +	if (!nn->client_pr_record_hashtbl)
>> +		return -ENOMEM;
>> +	spin_lock_init(&nn->client_pr_record_hashtbl_lock);
>> +	for (ix = 0; ix < CLIENT_HASH_SIZE; ix++)
>> +		INIT_LIST_HEAD(&nn->client_pr_record_hashtbl[ix]);
>> +	return 0;
> I guess there is precendent in the nfsd code in using this fixed size
> hash table, but they are not very scalable.  And using the rhastable
> API is actually relatively simple, so it might be easier to use that
> than rolling your own hash.
> 
> If you stick to the fixes size open code hash, you should use a
> hlist_head here.  There is no advantage in having a pointer to the tail
> entry for hashes, and the hlist saves half of the memory usage and
> improves cache efficiency.
> 
> But taking a step back:  why do we even need a new hash table here?
> Can't we jut hang off a list of block device for which a layout
> was granted off the nfs4_client structure given that we already
> have it available?

My question is: how many items will this table need to track,
on average? at maximum?


-- 
Chuck Lever