From: NeilBrown <neilb@suse.com>
To: David Laight <David.Laight@ACULAB.COM>,
'James Simmons' <jsimmons@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"devel\@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
Andreas Dilger <andreas.dilger@intel.com>,
Oleg Drokin <oleg.drokin@intel.com>,
Lai Siyao <lai.siyao@intel.com>,
Jinshan Xiong <jinshan.xiong@intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Lustre Development List" <lustre-devel@lists.lustre.org>,
Li Xi <lixi@ddn.com>, "Gu Zheng" <gzheng@ddn.com>
Subject: RE: [PATCH 1/4] staging: lustre: obdclass: change spinlock of key to rwlock
Date: Fri, 04 May 2018 09:26:36 +1000 [thread overview]
Message-ID: <87po2cfhhv.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <a3594bd7c393418c8fda5150a075ff1a@AcuMS.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Thu, May 03 2018, David Laight wrote:
> From: James Simmons
>> Sent: 02 May 2018 19:22
>> From: Li Xi <lixi@ddn.com>
>>
>> Most of the time, keys are never changed. So rwlock might be
>> better for the concurrency of key read.
>
> OTOH unless there is contention on the spin lock during reads the
> additional cost of a rwlock (probably double that of a spinlock)
> will hurt performance.
That's roughly what I was going to say - rwlocks are rarely a win.
I think the second patch which caused the lock to be taken less often
would have a bigger impact that the switch to rwlocks.
However I suspect a better approach would be to investigate some sort of
lockless solution.
I think the use of the spinlock in lu_context_key_register() could be
replaced with a careful cmp_xchg(). I'm less sure about
lu_context_key_degister(), but it might be possible.
>
> ...
>> - spin_lock(&lu_keys_guard);
>> + read_lock(&lu_keys_guard);
>> atomic_inc(&lu_key_initing_cnt);
>> - spin_unlock(&lu_keys_guard);
>> + read_unlock(&lu_keys_guard);
>
> WTF, seems unlikely that you need to hold any kind of lock
> over an atomic_inc().
>
> If this is just ensuring that no code holds the lock then
> it would need to request the write_lock().
> (and would need a comment)
There is a comment - that patch showed the last 2 lines of it.
This is for synchronization with lu_context_key_quiesce().
That spins(!! calling schedule, but still... not good) until
the lu_key_initing_cnt is zero while it holds the write lock.
Then it is sure that the code protected by this counter isn't
running.
I'm sure this can be improved! I would need to study it carefully to
see how.
Note that I don't object to these patches going in - if they provide a
measurable improvement which seems likely, then in they go. But I
hope the code won't stay like this long term.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2018-05-03 23:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-02 18:21 [PATCH 0/4] staging: lustre: obdclass: missing lu_object fixes James Simmons
2018-05-02 18:21 ` [PATCH 1/4] staging: lustre: obdclass: change spinlock of key to rwlock James Simmons
2018-05-03 13:50 ` David Laight
2018-05-03 23:26 ` NeilBrown [this message]
2018-05-04 0:11 ` Dilger, Andreas
2018-05-04 0:53 ` NeilBrown
2018-05-02 18:21 ` [PATCH 2/4] staging: lustre: obdclass: hoist locking in lu_context_exit() James Simmons
2018-05-02 18:21 ` [PATCH 3/4] staging: lustre: obdclass: guarantee all keys filled James Simmons
2018-05-02 18:21 ` [PATCH 4/4] staging: lustre: obdclass: change object lookup to no wait mode James Simmons
2018-05-04 1:15 ` NeilBrown
2018-05-15 0:37 ` James Simmons
2018-05-15 1:37 ` NeilBrown
2018-05-15 2:11 ` James Simmons
2018-05-07 1:47 ` Greg Kroah-Hartman
2018-05-08 11:45 ` Dan Carpenter
2018-05-15 15:02 ` James Simmons
2018-05-16 8:00 ` Dan Carpenter
2018-05-16 9:12 ` Dilger, Andreas
2018-05-16 15:44 ` Joe Perches
2018-05-16 16:57 ` Greg Kroah-Hartman
2018-05-17 5:07 ` James Simmons
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=87po2cfhhv.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=David.Laight@ACULAB.COM \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=gzheng@ddn.com \
--cc=jinshan.xiong@intel.com \
--cc=jsimmons@infradead.org \
--cc=lai.siyao@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lixi@ddn.com \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).