From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, josh@joshtriplett.org, niv@us.ibm.com,
tglx@linutronix.de, peterz@infradead.org, dhowells@redhat.com,
edumazet@google.com, darren@dvhart.com, sbw@mit.edu
Subject: Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?
Date: Fri, 6 Sep 2013 21:19:30 -0400 [thread overview]
Message-ID: <20130907011930.GA19943@Krystal> (raw)
In-Reply-To: <20130907004923.GD3966@linux.vnet.ibm.com>
* Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> On Fri, Sep 06, 2013 at 02:21:35PM -0400, Steven Rostedt wrote:
> > On Fri, 6 Sep 2013 10:52:38 -0700
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > > > What exactly does "extended quiescent state" mean? (Note, that's a
> > > > rhetorical question)
> > >
> > > In which case my rhetorical (and therefore useless) answer has to be
> > > "it is a quiescent state that is extended". ;-)
> > >
> > > Sorry, couldn't resist...
> >
> > Of course you couldn't ;)
> >
> > >
> > > > I wonder if we should change "rcu_cpu_ignore()" for "rcu_eqs_enter()"
> > > > and "rcu_cpu_heed()" for "rcu_eqs_exit()", as IMHO that's much more
> > > > straight forward to understand than trying to wrap you head around what
> > > > a quiescent state is, and why we are entering it or exiting it.
> > > >
> > > > It also flat out explains to people that rcu is not processing that
> > > > current CPU, and things like rcu_read_lock() should not be used.
> > > >
> > > > Then we can say "rcu_cpu_is_ignored()" for things like
> > > > "rcu_is_cpu_eqs()".
> > >
> > > Currently, none of RCU's _eqs functions are exported, so they have
> > > the potential to confuse only people working on the RCU implementation
> > > itself, who had better understand what "eqs" means.
> >
> > Yeah, that's what I thought, and never cared about the "eqs" meaning.
> >
> > >
> > > But I do count your vote against "eqs" appearing in the name of any
> > > function exported by RCU.
> >
> > Right, their shouldn't be any "eqs" functions that are global to users
> > outside of the RCU infrastructure.
> >
> > >
> > > How about if I made rcu_is_cpu_idle() be as follows?
> > >
> > > int rcu_is_cpu_idle(void)
> > > {
> > > int ret;
> > >
> > > ret = (atomic_read(&per_cpu(rcu_dynticks.dynticks,
> > > raw_smp_processor_id())) & 0x1) == 0;
> > > return ret;
> > > }
> > >
> > > This should allow existing uses to function properly and should allow
> > > you to use it as well.
> > >
> >
> > You already said it wont work, but I still would have been against
> > using it, because I wouldn't be checking if rcu thinks the CPU is idle,
> > as NO_HZ_FULL has nothing to do with idle.
>
> OK then, how about the following?
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> rcu: Is it safe to enter an RCU read-side critical section?
>
> There is currently no way for kernel code to determine whether it
> is safe to enter an RCU read-side critical section, in other words,
> whether or not RCU is paying attention to the currently running CPU.
> Given the large and increasing quantity of code shared by the idle loop
> and non-idle code, the this shortcoming is becoming increasingly painful.
>
> This commit therefore adds rcu_watching_this_cpu(), which returns true
> if it is safe to enter an RCU read-side critical section on the currently
> running CPU. This function is quite fast, using only a __this_cpu_read().
> However, the caller must disable preemption.
Hi Paul,
Hopefully I won't be redundant with other prior comments, but how about
the following:
static inline __rcu_read_check(void):
- checks if it is safe to enter a RCU read-side critical section in
the current context.
- requires that the caller disable preemption.
static inline rcu_read_check(void):
- disables preemption and inlines __rcu_read_check().
I don't think it is semantically a good thing to bury the
implementation-specific detail (whether is RCU watched on this
particular CPU) into the API naming. Also, I think the generic version
of this check should require no "special knowledge" from the user, hence
my double-underscores proposal for the optimized version.
Thoughts ?
Thanks,
Mathieu
>
> Reported-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 5b444e0..a41eb35 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -261,6 +261,10 @@ static inline void rcu_user_hooks_switch(struct task_struct *prev,
> rcu_irq_exit(); \
> } while (0)
>
> +#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) || defined(CONFIG_SMP)
> +extern int rcu_is_cpu_idle(void);
> +#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) || defined(CONFIG_SMP) */
> +
> /*
> * Infrastructure to implement the synchronize_() primitives in
> * TREE_RCU and rcu_barrier_() primitives in TINY_RCU.
> @@ -297,10 +301,6 @@ static inline void destroy_rcu_head_on_stack(struct rcu_head *head)
> }
> #endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
>
> -#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP)
> -extern int rcu_is_cpu_idle(void);
> -#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP) */
> -
> #if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PROVE_RCU)
> bool rcu_lockdep_current_cpu_online(void);
> #else /* #if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PROVE_RCU) */
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index e31005e..67fe672 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -132,4 +132,13 @@ static inline void rcu_scheduler_starting(void)
> }
> #endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
>
> +#ifdef CONFIG_RCU_TRACE
> +
> +static inline bool rcu_watching_this_cpu(void)
> +{
> + return !rcu_is_cpu_idle();
> +}
> +
> +#endif /* #ifdef CONFIG_RCU_TRACE */
> +
> #endif /* __LINUX_RCUTINY_H */
> diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
> index 226169d..c605b41 100644
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -90,4 +90,6 @@ extern void exit_rcu(void);
> extern void rcu_scheduler_starting(void);
> extern int rcu_scheduler_active __read_mostly;
>
> +extern bool rcu_watching_this_cpu(void);
> +
> #endif /* __LINUX_RCUTREE_H */
> diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
> index 7e3b0d6..b14701f 100644
> --- a/kernel/rcutiny.c
> +++ b/kernel/rcutiny.c
> @@ -176,7 +176,7 @@ void rcu_irq_enter(void)
> }
> EXPORT_SYMBOL_GPL(rcu_irq_enter);
>
> -#ifdef CONFIG_DEBUG_LOCK_ALLOC
> +#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE)
>
> /*
> * Test whether RCU thinks that the current CPU is idle.
> @@ -187,7 +187,7 @@ int rcu_is_cpu_idle(void)
> }
> EXPORT_SYMBOL(rcu_is_cpu_idle);
>
> -#endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> +#endif /* defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) */
>
> /*
> * Test whether the current CPU was interrupted from idle. Nested
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index a06d172..38c6883 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -666,6 +666,19 @@ int rcu_is_cpu_idle(void)
> }
> EXPORT_SYMBOL(rcu_is_cpu_idle);
>
> +/**
> + * rcu_watching_this_cpu - are RCU read-side critical sections safe?
> + *
> + * Return true if RCU is watching the running CPU, which means that
> + * this CPU can safely enter RCU read-side critical sections. Unlike
> + * rcu_is_cpu_idle(), the caller of rcu_watching_this_cpu() must have at
> + * least disabled preemption.
> + */
> +bool rcu_watching_this_cpu(void)
> +{
> + return !!__this_cpu_read(rcu_dynticks.dynticks_nesting);
> +}
> +
> #if defined(CONFIG_PROVE_RCU) && defined(CONFIG_HOTPLUG_CPU)
>
> /*
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2013-09-07 1:19 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 19:52 [PATCH] rcu: Is it safe to enter an RCU read-side critical section? Paul E. McKenney
2013-09-05 20:25 ` Steven Rostedt
2013-09-05 20:59 ` Paul E. McKenney
2013-09-05 21:05 ` Paul E. McKenney
2013-09-05 23:40 ` Steven Rostedt
2013-09-06 10:59 ` Frederic Weisbecker
2013-09-06 15:18 ` Paul E. McKenney
2013-09-06 15:33 ` Steven Rostedt
2013-09-06 16:40 ` Frederic Weisbecker
2013-09-06 16:52 ` Steven Rostedt
2013-09-06 16:58 ` Paul E. McKenney
2013-09-06 17:00 ` Frederic Weisbecker
2013-09-06 17:16 ` Steven Rostedt
2013-09-06 17:52 ` Paul E. McKenney
2013-09-06 17:56 ` Paul E. McKenney
2013-09-06 18:21 ` Steven Rostedt
2013-09-07 0:49 ` Paul E. McKenney
2013-09-07 1:19 ` Mathieu Desnoyers [this message]
2013-09-08 1:55 ` Paul E. McKenney
2013-09-09 10:56 ` Peter Zijlstra
2013-09-06 17:21 ` Eric Dumazet
2013-09-06 17:41 ` Paul E. McKenney
2013-09-06 18:59 ` Frederic Weisbecker
2013-09-06 20:38 ` Paul E. McKenney
2013-09-09 10:53 ` Peter Zijlstra
2013-09-09 12:13 ` Frederic Weisbecker
2013-09-09 12:39 ` Steven Rostedt
2013-09-09 12:45 ` Frederic Weisbecker
2013-09-09 12:55 ` Steven Rostedt
2013-09-09 13:08 ` Frederic Weisbecker
2013-09-09 13:21 ` Steven Rostedt
2013-09-09 13:29 ` Paul E. McKenney
2013-09-09 13:29 ` Steven Rostedt
2013-09-09 13:37 ` Peter Zijlstra
2013-09-09 13:48 ` Paul E. McKenney
2013-09-09 14:40 ` Frederic Weisbecker
2013-09-09 15:20 ` Steven Rostedt
2013-09-09 15:39 ` Steven Rostedt
2013-09-09 16:03 ` Frederic Weisbecker
2013-09-09 16:09 ` Paul E. McKenney
2013-09-09 16:30 ` Steven Rostedt
2013-09-09 16:56 ` Paul E. McKenney
2013-09-09 16:21 ` Peter Zijlstra
2013-09-09 13:45 ` Frederic Weisbecker
2013-09-09 13:56 ` Paul E. McKenney
2013-09-09 14:16 ` Steven Rostedt
2013-09-09 16:17 ` Paul E. McKenney
2013-09-09 16:34 ` Steven Rostedt
2013-09-09 16:58 ` Paul E. McKenney
2013-09-09 17:06 ` Steven Rostedt
2013-09-09 17:45 ` Paul E. McKenney
2013-09-09 17:29 ` Mathieu Desnoyers
2013-09-09 17:56 ` Paul E. McKenney
2013-09-09 18:36 ` Steven Rostedt
2013-09-09 18:50 ` Paul E. McKenney
2013-09-09 21:40 ` Mathieu Desnoyers
2013-09-09 21:59 ` Steven Rostedt
2013-09-09 22:34 ` Paul E. McKenney
2013-09-11 14:13 ` Paul E. McKenney
2013-09-11 14:26 ` Steven Rostedt
2013-09-11 15:23 ` Paul E. McKenney
2013-09-11 15:49 ` Steven Rostedt
2013-09-11 16:03 ` Paul E. McKenney
2013-09-09 13:14 ` Peter Zijlstra
2013-09-09 13:29 ` Frederic Weisbecker
2013-09-09 13:41 ` Steven Rostedt
2013-09-09 13:49 ` Frederic Weisbecker
2013-09-09 13:50 ` Paul E. McKenney
2013-09-09 13:46 ` Paul E. McKenney
2013-09-09 13:55 ` Steven Rostedt
2013-09-09 16:22 ` Paul E. McKenney
2013-09-09 16:40 ` Steven Rostedt
2013-09-09 17:45 ` Paul E. McKenney
2013-09-09 13:23 ` Paul E. McKenney
2013-09-09 13:36 ` Peter Zijlstra
2013-09-09 13:53 ` Paul E. McKenney
2013-09-09 16:18 ` Peter Zijlstra
2013-09-09 14:49 ` Christoph Lameter
2013-09-09 15:08 ` Peter Zijlstra
2013-09-09 15:24 ` Christoph Lameter
2013-09-09 15:41 ` Steven Rostedt
2013-09-09 15:47 ` Steven Rostedt
2013-09-09 16:00 ` Ingo Molnar
2013-09-09 16:03 ` Steven Rostedt
2013-09-09 16:11 ` Ingo Molnar
2013-09-10 21:37 ` Christoph Lameter
2013-09-12 6:39 ` Ingo Molnar
2013-09-12 14:20 ` Christoph Lameter
2013-09-10 21:28 ` Christoph Lameter
2013-09-12 6:38 ` Ingo Molnar
2013-09-12 14:43 ` Christoph Lameter
2013-09-09 16:15 ` Peter Zijlstra
2013-09-10 4:07 ` Mike Galbraith
2013-09-09 13:36 ` Steven Rostedt
2013-09-09 14:21 ` Peter Zijlstra
2013-09-09 16:26 ` Paul E. McKenney
2013-09-09 16:42 ` Steven Rostedt
2013-09-09 16:59 ` 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=20130907011930.GA19943@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
/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.