From: Benny Halevy <bhalevy@primarydata.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: bfields@redhat.com, NFS list <linux-nfs@vger.kernel.org>
Subject: Re: state lock elimination
Date: Wed, 16 Oct 2013 11:21:28 +0300 [thread overview]
Message-ID: <525E4C88.9050701@primarydata.com> (raw)
In-Reply-To: <20131016064243.GA28758@infradead.org>
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
next parent reply other threads:[~2013-10-16 8:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20131015211445.GA23636@infradead.org>
[not found] ` <525DB943.3010707@primarydata.com>
[not found] ` <20131016064243.GA28758@infradead.org>
2013-10-16 8:21 ` Benny Halevy [this message]
2013-10-16 18:22 ` state lock elimination Christoph Hellwig
[not found] ` <525E2C5C.4020104@primarydata.com>
[not found] ` <20131016064649.GB28758@infradead.org>
2013-10-16 8:45 ` nfs4_file usage Benny Halevy
2013-10-16 8:51 ` Christoph Hellwig
2013-10-16 12:18 ` Benny Halevy
2013-10-16 12:33 ` Christoph Hellwig
2013-10-16 12:48 ` Benny Halevy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525E4C88.9050701@primarydata.com \
--to=bhalevy@primarydata.com \
--cc=bfields@redhat.com \
--cc=hch@infradead.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.