From: Benny Halevy <bhalevy@panasas.com>
To: Peter Staubach <staubach@redhat.com>
Cc: "J. Bruce Fields" <bfields@citi.umich.edu>,
linux-nfs@vger.kernel.org, pnfs@linux-nfs.org
Subject: Re: [pnfs] [RFC 01/11] nfsd: introduce nfs4_client state
Date: Thu, 17 Dec 2009 01:17:01 +0200 [thread overview]
Message-ID: <4B296A6D.8090108@panasas.com> (raw)
In-Reply-To: <4B29604A.7080701@redhat.com>
On Dec. 17, 2009, 0:33 +0200, Peter Staubach <staubach@redhat.com> wrote:
> Benny Halevy wrote:
>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
>> ---
>> fs/nfsd/state.h | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h
>> index fefeae2..7e67eca 100644
>> --- a/fs/nfsd/state.h
>> +++ b/fs/nfsd/state.h
>> @@ -186,6 +186,13 @@ struct nfsd4_sessionid {
>>
>> #define HEXDIR_LEN 33 /* hex version of 16 byte md5 of cl_name plus '\0' */
>>
>> +/* nfs4_client states */
>> +enum nfs4_client_state {
>> + CL_STATE_NORMAL,
>> + CL_STATE_RENEW,
>> + CL_STATE_EXPIRED,
>> +};
>> +
>> /*
>> * struct nfs4_client - one per client. Clientids live here.
>> * o Each nfs4_client is hashed by clientid.
>> @@ -214,6 +221,7 @@ struct nfs4_client {
>> nfs4_verifier cl_confirm; /* generated by server */
>> struct nfs4_cb_conn cl_cb_conn; /* callback info */
>> atomic_t cl_count; /* ref count */
>> + atomic_t cl_state; /* renew / expiry state */
>
> The use of an atomic here seems complex and makes the
> implementation seem fragile to me. Is the atomic_cmpxchg()
> really going to save much time over just using a spinlock
> and normal loads and stores to retrieve and get the value
> of cl_state? A spinlock would make things much more
> obvious how they were supposed to work, to me, at least.
>
This can be done of course, though logically, I'd still
consider defining the equivalent of cmpxchg as a static
inline helper since it does exactly what I want to to.
As for efficiency the cmpxchg is more as efficient as
an uncontended fine grain lock, with no chance of spinning.
atomic_t also has a smaller memory footprint than a
fine grain lock (per nsf4_client). Using a coarse grain
lock is possible but will needless increase the chances
for contention.
Benny
> Thanx...
>
> ps
>
>> u32 cl_firststate; /* recovery dir creation */
>>
>> /* for nfs41 */
>
next prev parent reply other threads:[~2009-12-16 23:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-16 17:39 [RFC 0/11] state lock reduction prep Benny Halevy
2009-12-16 17:40 ` [RFC 01/11] nfsd: introduce nfs4_client state Benny Halevy
2009-12-16 22:33 ` [pnfs] " Peter Staubach
2009-12-16 23:17 ` Benny Halevy [this message]
2009-12-16 17:40 ` [RFC 02/11] nfsd: mark client state as expired in expire_client Benny Halevy
2009-12-16 17:40 ` [RFC 03/11] nfsd: introduce get_nfs4_client Benny Halevy
2009-12-16 17:41 ` [RFC 04/11] nfsd: mark client for renew Benny Halevy
2009-12-16 20:48 ` J. Bruce Fields
2009-12-16 20:53 ` J. Bruce Fields
2009-12-16 21:56 ` Benny Halevy
2009-12-16 22:06 ` J. Bruce Fields
2009-12-16 22:23 ` Benny Halevy
2009-12-17 20:19 ` J. Bruce Fields
2009-12-16 17:41 ` [RFC 05/11] nfsd: skip clients marked for renewal Benny Halevy
2009-12-16 20:58 ` J. Bruce Fields
2009-12-16 21:54 ` Benny Halevy
2009-12-16 17:41 ` [RFC 06/11] nfsd41: no need to hold the state lock around mark_client_for_renew Benny Halevy
2009-12-16 17:41 ` [RFC 07/11] nfsd: rename recall_lock to deleg_lock Benny Halevy
2009-12-16 17:42 ` [RFC 08/11] nfsd: use deleg_lock to protect dl_perfile and dl_perclnt Benny Halevy
2009-12-16 17:42 ` [RFC 09/11] nfsd: get a reference count on the delgation while outside of the deleg_lock Benny Halevy
2009-12-16 17:42 ` [RFC 10/11] nfsd: close delegation only on last reference Benny Halevy
2009-12-16 21:18 ` J. Bruce Fields
2009-12-16 22:04 ` Benny Halevy
2009-12-16 17:42 ` [RFC 11/11] nfsd: refactor unhash_delegation 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=4B296A6D.8090108@panasas.com \
--to=bhalevy@panasas.com \
--cc=bfields@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=pnfs@linux-nfs.org \
--cc=staubach@redhat.com \
/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.