From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Simon Horman <horms@verge.net.au>, 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>,
dhaval.giani@gmail.com
Subject: Re: [PATCH 2/2] ipvs: Use cond_resched_rcu_lock() helper when dumping connections
Date: Mon, 29 Apr 2013 14:30:02 -0700 [thread overview]
Message-ID: <20130429213002.GP3780@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1304292356220.1822@ja.ssi.bg>
On Tue, Apr 30, 2013 at 12:08:18AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Sat, 27 Apr 2013, Paul E. McKenney wrote:
>
> > On Sat, Apr 27, 2013 at 02:32:48PM +0300, Julian Anastasov wrote:
> > >
> > > So, I assume, to help realtime kernels and rcu_barrier
> > > it is not a good idea to guard rcu_read_unlock with checks.
> > > I see that rcu_read_unlock will try to reschedule in the
> > > !CONFIG_PREEMPT_RCU case (via preempt_enable), can we
> > > use ifdefs to avoid double TIF_NEED_RESCHED check?:
> > >
> > > rcu_read_unlock();
> > > #if !defined(CONFIG_PREEMPT) || defined(CONFIG_PREEMPT_RCU)
> >
> > I would instead suggest something like:
> >
> > #ifndef CONFIG_PREEMPT_RCU
> >
> > But yes, in the CONFIG_PREEMPT_RCU case, the cond_resched() is not
> > needed.
>
> Hm, is this correct? If I follow the ifdefs
> preempt_schedule is called when CONFIG_PREEMPT is
> defined _and_ CONFIG_PREEMPT_RCU is not defined.
> Your example for CONFIG_PREEMPT_RCU is the opposite to this?
Yep, I really did intend to say "#ifndef CONFIG_PREEMPT_RCU".
A couple of things to keep in mind:
1. Although rcu_read_unlock() does map to preempt_enable() for
CONFIG_TINY_RCU and CONFIG_TREE_RCU, the current Kconfig refuses
to allow either CONFIG_TINY_RCU or CONFIG_TREE_RCU to be selected
if CONFIG_PREEMPT=y.
2. In the CONFIG_PREEMPT_RCU case, __rcu_read_unlock() will check
to see if the RCU core needs to be informed, so there is no
need to invoke cond_resched() in that case.
3. If we drop your "|| defined(CONFIG_PREEMPT_RCU)", we get an
almost-synonym for my "#ifndef CONFIG_PREEMPT_RCU". The "almost"
applies to older kernels due to the possibility of having a
CONFIG_TINY_PREEMPT_RCU kernel -- but this possibility is going
away soon.
Make sense?
Thanx, Paul
> > > cond_resched();
> > > #endif
> > > rcu_read_lock();
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
next prev parent reply other threads:[~2013-04-29 21:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-26 1:45 [PATCH 0/2] sched: Add cond_resched_rcu_lock() helper Simon Horman
2013-04-26 1:45 ` [PATCH 1/2] " Simon Horman
2013-04-26 6:13 ` Ingo Molnar
2013-04-26 1:45 ` [PATCH 2/2] ipvs: Use cond_resched_rcu_lock() helper when dumping connections Simon Horman
2013-04-26 6:15 ` Ingo Molnar
2013-04-30 2:45 ` Simon Horman
2013-04-26 8:03 ` Peter Zijlstra
2013-04-26 15:45 ` Paul E. McKenney
2013-04-26 15:59 ` Eric Dumazet
2013-04-26 16:30 ` Paul E. McKenney
2013-04-26 17:19 ` Peter Zijlstra
2013-04-26 17:48 ` Paul E. McKenney
2013-04-26 18:26 ` Eric Dumazet
2013-04-26 19:04 ` Paul E. McKenney
2013-04-27 7:18 ` Peter Zijlstra
2013-04-27 16:17 ` Paul E. McKenney
2013-04-27 11:32 ` Julian Anastasov
2013-04-27 16:20 ` Paul E. McKenney
2013-04-29 21:08 ` Julian Anastasov
2013-04-29 21:30 ` Paul E. McKenney [this message]
2013-04-29 23:12 ` Julian Anastasov
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=20130429213002.GP3780@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dhaval.giani@gmail.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.