All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Julian Anastasov <ja@ssi.bg>, Simon Horman <horms@verge.net.au>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
	netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Dipankar Sarma <dipankar@in.ibm.com>
Subject: Re: [PATCH v2 1/2] sched: Add cond_resched_rcu_lock() helper
Date: Wed, 1 May 2013 07:32:58 -0700	[thread overview]
Message-ID: <20130501143258.GA31577@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130501124637.GO3780@linux.vnet.ibm.com>

On Wed, May 01, 2013 at 05:46:37AM -0700, Paul E. McKenney wrote:
> On Wed, May 01, 2013 at 11:10:12AM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 30, 2013 at 10:52:38AM +0300, Julian Anastasov wrote:
> > > 
> > > 	Hello,
> > > 
> > > On Tue, 30 Apr 2013, Simon Horman wrote:
> > > 
> > > > > > +static void inline cond_resched_rcu_lock(void)
> > > > > > +{
> > > > > > +	if (need_resched()) {
> > > > > 
> > > > > 	Ops, it should be without above need_resched.
> > > > 
> > > > Thanks, to clarify, just this:
> > > > 
> > > > static void inline cond_resched_rcu_lock(void)
> > > > {
> > > > 	rcu_read_unlock();
> > > > #ifndef CONFIG_PREEMPT_RCU
> > > > 	cond_resched();
> > > > #endif
> > > > 	rcu_read_lock();
> > > > }
> > > 
> > > 	Yes, thanks!
> > 
> > OK, now I'm confused.. PREEMPT_RCU would preempt in any case, so why bother
> > dropping rcu_read_lock() at all?
> 
> Good point, I was assuming that the goal was to let grace periods end
> as well as to allow preemption.  The momentary dropping out of the
> RCU read-side critical section allows the grace periods to end.
> 
> > That is; the thing that makes sense to me is:
> > 
> > static void inline cond_resched_rcu_lock(void)
> > {
> > #ifdef CONFIG_PREEMPT_RCU
> > 	if (need_resched()) {
> > 		rcu_read_unlock();
> > 		cond_resched();
> > 		rcu_read_lock();
> > 	}
> > #endif /* CONFIG_PREEMPT_RCU */
> > }
> > 
> > That would have an rcu_read_lock() break and voluntary preemption point for
> > non-preemptible RCU and not bother with the stuff for preemptible RCU.
> 
> If the only goal is to allow preemption, and if long grace periods are
> not a concern, then this alternate approach would work fine as well.

But now that I think about it, there is one big advantage to the
unconditional exiting and reentering the RCU read-side critical section:
It allows easy placement of unconditional lockdep debug code to catch
the following type of bug:

	rcu_read_lock();
	...
	rcu_read_lock();
	...
	cond_resched_rcu_lock();
	...
	rcu_read_unlock();
	...
	rcu_read_unlock();

Here is how to detect this:

	static void inline cond_resched_rcu_lock(void)
	{
		rcu_read_unlock();
		WARN_ON_ONCE(rcu_read_lock_held());
	#ifndef CONFIG_PREEMPT_RCU
		cond_resched();
	#endif
		rcu_read_lock();
	}

Of course, we could do this in your implementation as well:

	static void inline cond_resched_rcu_lock(void)
	{
	#ifdef CONFIG_PREEMPT_RCU
		if (need_resched()) {
			rcu_read_unlock();
			WARN_ON_ONCE(rcu_read_lock_held());
			cond_resched();
			rcu_read_lock();
		}
	#endif /* CONFIG_PREEMPT_RCU */
	}

But this would fail to detect the bug -- and would silently fail -- on
!CONFIG_PREEMPT_RCU systems.

							Thanx, Paul

> Of course, both approaches assume that the caller is in a place
> where having all RCU-protected data disappear is OK!
> 
> 							Thanx, Paul


  reply	other threads:[~2013-05-01 14:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-30  2:52 [PATCH v2 0/2] sched: Add cond_resched_rcu_lock() helper Simon Horman
2013-04-30  2:52 ` [PATCH v2 1/2] " Simon Horman
2013-04-30  7:12   ` Julian Anastasov
2013-04-30  7:29     ` Simon Horman
2013-04-30  7:52       ` Julian Anastasov
2013-05-01  9:10         ` Peter Zijlstra
2013-05-01 12:46           ` Paul E. McKenney
2013-05-01 14:32             ` Paul E. McKenney [this message]
2013-05-02  7:27               ` Peter Zijlstra
2013-05-01 15:17             ` Peter Zijlstra
2013-05-01 15:29               ` Eric Dumazet
2013-05-01 15:59                 ` Peter Zijlstra
2013-05-01 16:02                 ` Paul E. McKenney
2013-05-01 16:57                   ` Peter Zijlstra
2013-05-01 17:30                     ` Paul E. McKenney
2013-05-01 14:22           ` Julian Anastasov
2013-05-01 15:55             ` Peter Zijlstra
2013-05-01 18:22               ` Julian Anastasov
2013-05-01 19:04                 ` Paul E. McKenney
2013-05-02  7:26                 ` Peter Zijlstra
2013-05-02 10:06                   ` Julian Anastasov
2013-05-02 15:54                   ` Julian Anastasov
2013-05-02 17:32                     ` Paul E. McKenney
2013-05-02 17:32                       ` Paul E. McKenney
2013-05-02 18:55                       ` Julian Anastasov
2013-05-02 19:24                         ` Julian Anastasov
2013-05-02 19:34                         ` Paul E. McKenney
2013-05-02 20:19                           ` Julian Anastasov
2013-05-02 22:31                             ` Paul E. McKenney
2013-05-03  7:52                               ` Julian Anastasov
2013-05-03 16:30                                 ` Paul E. McKenney
2013-05-03 17:04                                   ` Peter Zijlstra
2013-05-03 17:34                                     ` Paul E. McKenney
2013-05-03 18:09                                       ` Peter Zijlstra
2013-05-03 17:47                                   ` Julian Anastasov
2013-05-04  7:23                                   ` Julian Anastasov
2013-05-04 18:03                                     ` Paul E. McKenney
2013-04-30  2:52 ` [PATCH v2 2/2] ipvs: Use cond_resched_rcu_lock() helper when dumping connections Simon Horman

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=20130501143258.GA31577@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=dipankar@in.ibm.com \
    --cc=eric.dumazet@gmail.com \
    --cc=horms@verge.net.au \
    --cc=ja@ssi.bg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvs-devel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=peterz@infradead.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.