From: Oleg Nesterov <oleg@redhat.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Daniel Wagner <daniel.wagner@bmw-carit.de>,
Davidlohr Bueso <dave@stgolabs.net>,
Ingo Molnar <mingo@redhat.com>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] rcu: Create rcu_sync infrastructure
Date: Wed, 15 Jul 2015 20:41:03 +0200 [thread overview]
Message-ID: <20150715184103.GA2101@redhat.com> (raw)
In-Reply-To: <20150715180546.GJ3717@linux.vnet.ibm.com>
On 07/15, Paul E. McKenney wrote:
>
> On Sun, Jul 12, 2015 at 01:35:48AM +0200, Oleg Nesterov wrote:
> > It is functionally equivalent to
> >
> > struct rcu_sync_struct {
> > atomic_t counter;
> > };
> >
> > static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
> > {
>
> If you add an smp_mb() here...
I don't think so, please see below...
> > static inline void rcu_sync_exit(struct rcu_sync_struct *rss)
> > {
> > synchronize_sched();
>
> You should be able to demote the above synchronize_sched() to an
> smp_mb__before_atomic(). Even rare writes should make this tradeoff
> worthwhile.
This is irrelevant I think, this (pseudo) code just tries to explain
what this interface does.
> > +static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
> > +{
>
> smp_mb(); /* A: Ensure that reader sees last update. */
> /* Pairs with B. */
>
Let me remind you about your f0a0e6f282c72247e7c8ec "rcu: Clarify
memory-ordering properties of grace-period primitives" documentation
patch ;)
We do not need any barrier, assuming that this is called under
preempt_disable/etc.
rcu_sync_is_idle() becomes true after another gp pass. The reader
should see all updates after that.
> > +void rcu_sync_exit(struct rcu_sync_struct *rss)
> > +{
> > + spin_lock_irq(&rss->rss_lock);
>
> smp_mb(); /* B: Make sure next readers see critical section. */
> /* Pairs with A. */
>
> > + if (!--rss->gp_count) {
>
> At which point, I believe you can ditch the callback entirely, along
> with ->cb_state.
>
> So, what am I missing here?
Please see above. We start anothe gp before "unlock" to avoid mb's in
the reader's code.
> Are readers really so frequent that the
> added read-side memory barrier is visible?
But this code is heavily optimized for the readers. And please see
another discussion about sb_writers and percpu_rw_semaphore. I was
suprized, but mb() in sb_start_write() is actually noticeable.
> Given that the current
> code forces the readers to grab ->rss_lock
Where? the readers never take this lock.
Oleg.
next prev parent reply other threads:[~2015-07-15 18:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 23:35 [PATCH 0/7] Add rcu_sync infrastructure to avoid _expedited() in percpu-rwsem Oleg Nesterov
2015-07-11 23:35 ` [PATCH 1/7] rcu: Create rcu_sync infrastructure Oleg Nesterov
2015-07-15 18:05 ` Paul E. McKenney
2015-07-15 18:15 ` Peter Zijlstra
2015-07-15 18:28 ` Paul E. McKenney
2015-07-15 19:08 ` Oleg Nesterov
2015-07-15 19:15 ` Paul E. McKenney
2015-07-15 18:41 ` Oleg Nesterov [this message]
2015-07-11 23:35 ` [PATCH 2/7] rcusync: Introduce struct rcu_sync_ops Oleg Nesterov
2015-07-11 23:35 ` [PATCH 3/7] rcusync: Add the CONFIG_PROVE_RCU checks Oleg Nesterov
2015-07-11 23:35 ` [PATCH 4/7] rcusync: Introduce rcu_sync_dtor() Oleg Nesterov
2015-07-11 23:36 ` [PATCH 5/7] percpu-rwsem: change it to rely on rss_sync infrastructure Oleg Nesterov
2015-07-15 18:15 ` Paul E. McKenney
2015-07-15 18:59 ` Oleg Nesterov
2015-07-11 23:36 ` [PATCH 6/7] percpu-rwsem: fix the comments outdated by rcu_sync Oleg Nesterov
2015-07-11 23:36 ` [PATCH 7/7] percpu-rwsem: cleanup the lockdep annotations in percpu_down_read() Oleg Nesterov
2015-07-11 23:47 ` [PATCH 0/7] Add rcu_sync infrastructure to avoid _expedited() in percpu-rwsem Linus Torvalds
2015-07-15 18:27 ` Paul E. McKenney
2015-07-15 19:36 ` Oleg Nesterov
2015-07-15 21:59 ` Paul E. McKenney
2015-07-17 23:29 ` Oleg Nesterov
2015-07-17 23:47 ` Paul E. McKenney
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=20150715184103.GA2101@redhat.com \
--to=oleg@redhat.com \
--cc=daniel.wagner@bmw-carit.de \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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.