On 2013-10-01 16:37, Christoph Hellwig wrote:
> On Tue, Oct 01, 2013 at 04:31:21PM +0300, Benny Halevy wrote:
>> So the reason not to hold it is that the nfs state lock is global to the
>> server and blocks all state modifying operations such as:
>> open, close, lock, clientid, session operations, etc.
>
> While not really related to this patch: what's the reason it's not
> split? The way nfsd works there should be almost no state that isn't
> per-export.
I'll defer to Bruce. We did reduce the use of the state_lock in the past
but I think there is potential for further reducing what it covers.
Memory allocations for client, file, stateid etc. and can be optimized for
the common path by opportunistically allocating these after a quick
search (lockless of rcu_read is possible)
In the uncommon case insertion of the newly allocated stuff would fail and
they will be freed.
The candidates I can quickly see are:
- the idr calls manipulating and looking up the different stateid hash tables,
- clientid rb_trees, and
- file hash table
- currently protected with the recall_lock spin_lock but we can factor out,
I think, the call to nfsd4_alloc_file and combine find_file and nfsd4_init_file
for conditional insertion under the recall_lock.
Benny
>
> --
> 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
>
--
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
