linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).