public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox