On 2013-10-16 09:42, Christoph Hellwig wrote:
>> A lot of crap ended up under the client_mutex that we need to untangle.
>> My general direction is:
>> - use a spin lock for all non-blocking sections (rename recall_lock to state_lock for that)
>
> Any chance we can avoid global locks for most of this? Global locks
> really suck for scalability, and in nfsd we should be able to do most
> things per-export at least.
>
I tried reducing the lock scope but the problem is that we hash state
on objects with different scopes of access, particularly net/client vs. file
and the hashing needs to be consistent and atomic.
>> - for state mutating nfs4 ops like open/close/lock/... use wait_on_bit to serialize access
>> *per open owner* rather than globally.
>
> per open owner sounds good. Not a huge fan of bit locks as they make
> debugging very hard, though.
I'll try using a refcount and mutex first as per Bruce's current direction with stateowners.
>
> I'll look over your changes soon, btw.
>
Thanks!
The WIP version is in git://linux-nfs/~bhalevy/linux-pnfs.git state-lock-elim
if anyone else is interested in previewing the patchset in its current drafty state)
Benny
On Wed, Oct 16, 2013 at 11:21:28AM +0300, Benny Halevy wrote:
> I tried reducing the lock scope but the problem is that we hash state
> on objects with different scopes of access, particularly net/client vs. file
> and the hashing needs to be consistent and atomic.
Lists, Hashes or similar lookup data structures are generally not the
hard part, as it's enough to lock the data structure that the hash or
list hangs off. No need to involve looks in the structure pointed to.