All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Lai Jiangshan" <laijs@cn.fujitsu.com>,
	"Dipankar Sarma" <dipankar@in.ibm.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	"Josh Triplett" <josh@joshtriplett.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"David Howells" <dhowells@redhat.com>,
	"Eric Dumazet" <edumazet@google.com>,
	dvhart@linux.intel.com,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Oleg Nesterov" <oleg@redhat.com>
Subject: Re: [PATCH v5 tip/core/rcu 11/16] rcu: Defer rcu_tasks_kthread() creation till first call_rcu_tasks()
Date: Thu, 14 Aug 2014 15:53:44 -0700	[thread overview]
Message-ID: <20140814225344.GB4752@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJhHMCAvzXUgCuiO5nDB0oZYkFsyJ1bdJmz5JML4jrLrC5F0qw@mail.gmail.com>

On Thu, Aug 14, 2014 at 06:28:53PM -0400, Pranith Kumar wrote:
> On Mon, Aug 11, 2014 at 6:49 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> >
> > It is expected that many sites will have CONFIG_TASKS_RCU=y, but
> > will never actually invoke call_rcu_tasks().  For such sites, creating
> > rcu_tasks_kthread() at boot is wasteful.  This commit therefore defers
> > creation of this kthread until the time of the first call_rcu_tasks().
> >
> > This of course means that the first call_rcu_tasks() must be invoked
> > from process context after the scheduler is fully operational.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> >  kernel/rcu/update.c | 33 ++++++++++++++++++++++++++-------
> >  1 file changed, 26 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> > index 1256a900cd01..d997163c7e92 100644
> > --- a/kernel/rcu/update.c
> > +++ b/kernel/rcu/update.c
> > @@ -378,7 +378,12 @@ DEFINE_SRCU(tasks_rcu_exit_srcu);
> >  static int rcu_task_stall_timeout __read_mostly = HZ * 60 * 10;
> >  module_param(rcu_task_stall_timeout, int, 0644);
> >
> > -/* Post an RCU-tasks callback. */
> > +static void rcu_spawn_tasks_kthread(void);
> > +
> > +/*
> > + * Post an RCU-tasks callback.  First call must be from process context
> > + * after the scheduler if fully operational.
> > + */
> >  void call_rcu_tasks(struct rcu_head *rhp, void (*func)(struct rcu_head *rhp))
> >  {
> >         unsigned long flags;
> > @@ -391,8 +396,10 @@ void call_rcu_tasks(struct rcu_head *rhp, void (*func)(struct rcu_head *rhp))
> >         *rcu_tasks_cbs_tail = rhp;
> >         rcu_tasks_cbs_tail = &rhp->next;
> >         raw_spin_unlock_irqrestore(&rcu_tasks_cbs_lock, flags);
> > -       if (needwake)
> > +       if (needwake) {
> > +               rcu_spawn_tasks_kthread();
> >                 wake_up(&rcu_tasks_cbs_wq);
> > +       }
> >  }
> >  EXPORT_SYMBOL_GPL(call_rcu_tasks);
> >
> > @@ -618,15 +625,27 @@ static int __noreturn rcu_tasks_kthread(void *arg)
> >         }
> >  }
> >
> > -/* Spawn rcu_tasks_kthread() at boot time. */
> > -static int __init rcu_spawn_tasks_kthread(void)
> > +/* Spawn rcu_tasks_kthread() at first call to call_rcu_tasks(). */
> > +static void rcu_spawn_tasks_kthread(void)
> >  {
> > -       struct task_struct __maybe_unused *t;
> > +       static DEFINE_MUTEX(rcu_tasks_kthread_mutex);
> > +       static struct task_struct *rcu_tasks_kthread_ptr;
> > +       struct task_struct *t;
> >
> > +       if (ACCESS_ONCE(rcu_tasks_kthread_ptr)) {
> > +               smp_mb(); /* Ensure caller sees full kthread. */
> > +               return;
> > +       }
> 
> I don't see the need for this smp_mb(). The caller has already seen
> that rcu_tasks_kthread_ptr is assigned. What are we ensuring with this
> barrier again?

We are ensuring that any later operations on rcu_tasks_kthread_ptr
see a fully initialized thread.  Because these later operations
might be loads, we cannot rely on control dependencies.

> an smp_rmb() before this ACCESS_ONCE() and an smp_wmb() after
> assigning to rcu_tasks_kthread_ptr should be enough, right?

Probably.  But given that rcu_spawn_tasks_kthread() is only called
when a CPU is onlined, I am not much inclined to weaken it.

> > +       mutex_lock(&rcu_tasks_kthread_mutex);
> > +       if (rcu_tasks_kthread_ptr) {
> > +               mutex_unlock(&rcu_tasks_kthread_mutex);
> > +               return;
> > +       }
> >         t = kthread_run(rcu_tasks_kthread, NULL, "rcu_tasks_kthread");
> >         BUG_ON(IS_ERR(t));
> > -       return 0;
> > +       smp_mb(); /* Ensure others see full kthread. */
> > +       ACCESS_ONCE(rcu_tasks_kthread_ptr) = t;
> 
> Isn't it better to reverse these two statements and change as follows?
> 
> ACCESS_ONCE(rcu_tasks_kthread_ptr) = t;
> smp_wmb();

This would break.  We need all the task creation stuff to be seen as
having happened before the store to rcu_tasks_kthread_ptr.  Putting
the barrier after the store to rcu_tasks_kthread_ptr would allow
both compiler and CPU to reorder task-creation stuff to follow the
store to the pointer, which would not be good.

> or
> 
> smp_store_release(rcu_tasks_kthread_ptr, t);
> 
> will ensure that this write to rcu_task_kthread_ptr is ordered with
> the previous read. I recently read memory-barriers.txt, so please
> excuse me if I am totally wrong. But I am confused! :(

Hmmm...  An smp_store_release() combined with smp_load_acquire()
up earlier might be a good approach.  Maybe as a future cleanup.

But please note that smp_store_release() puts the barrier -before-
the store.  ;-)

							Thanx, Paul

> > +       mutex_unlock(&rcu_tasks_kthread_mutex);
> >  }
> > -early_initcall(rcu_spawn_tasks_kthread);
> >
> >  #endif /* #ifdef CONFIG_TASKS_RCU */
> > --
> > 1.8.1.5
> >
> 
> 
> 
> -- 
> Pranith
> 


  reply	other threads:[~2014-08-14 22:53 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 22:48 [PATCH tip/core/rcu 0/16] RCU-tasks implementation Paul E. McKenney
2014-08-11 22:48 ` [PATCH v5 tip/core/rcu 01/16] rcu: Add call_rcu_tasks() Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 02/16] rcu: Provide cond_resched_rcu_qs() to force quiescent states in long loops Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 03/16] rcu: Add synchronous grace-period waiting for RCU-tasks Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 04/16] rcu: Make TASKS_RCU handle tasks that are almost done exiting Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 05/16] rcu: Export RCU-tasks APIs to GPL modules Paul E. McKenney
2014-08-14 19:08     ` Pranith Kumar
2014-08-14 21:29       ` Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 06/16] rcutorture: Add torture tests for RCU-tasks Paul E. McKenney
2014-08-14 21:34     ` Pranith Kumar
2014-08-14 21:44       ` Paul E. McKenney
2014-08-14 21:49         ` Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 07/16] rcutorture: Add RCU-tasks test cases Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 08/16] rcu: Add stall-warning checks for RCU-tasks Paul E. McKenney
2014-08-14 21:39     ` Pranith Kumar
2014-08-14 21:59       ` Paul E. McKenney
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 09/16] rcu: Improve RCU-tasks energy efficiency Paul E. McKenney
2014-08-14 21:42     ` Pranith Kumar
2014-08-14 21:55       ` Paul E. McKenney
2014-08-14 22:00         ` Pranith Kumar
2014-08-11 22:48   ` [PATCH v5 tip/core/rcu 10/16] documentation: Add verbiage on RCU-tasks stall warning messages Paul E. McKenney
2014-08-11 22:49   ` [PATCH v5 tip/core/rcu 11/16] rcu: Defer rcu_tasks_kthread() creation till first call_rcu_tasks() Paul E. McKenney
2014-08-14 22:28     ` Pranith Kumar
2014-08-14 22:53       ` Paul E. McKenney [this message]
2014-08-11 22:49   ` [PATCH v5 tip/core/rcu 12/16] rcu: Make TASKS_RCU handle nohz_full= CPUs Paul E. McKenney
2014-08-14 22:55     ` Pranith Kumar
2014-08-14 23:16       ` Paul E. McKenney
2014-08-11 22:49   ` [PATCH v5 tip/core/rcu 13/16] rcu: Make rcu_tasks_kthread()'s GP-wait loop allow preemption Paul E. McKenney
2014-08-11 22:49   ` [PATCH v5 tip/core/rcu 14/16] rcu: Remove redundant preempt_disable() from rcu_note_voluntary_context_switch() Paul E. McKenney
2014-08-13 10:56     ` Peter Zijlstra
2014-08-13 14:07       ` Paul E. McKenney
2014-08-13 14:33         ` Peter Zijlstra
2014-08-13 20:06           ` Paul E. McKenney
2014-08-11 22:49   ` [PATCH v5 tip/core/rcu 15/16] rcu: Make RCU-tasks wait for idle tasks Paul E. McKenney
2014-08-13  8:12     ` Peter Zijlstra
2014-08-13 12:48       ` Paul E. McKenney
2014-08-13 13:40         ` Peter Zijlstra
2014-08-13 13:51           ` Steven Rostedt
2014-08-13 14:07             ` Peter Zijlstra
2014-08-13 14:13               ` Steven Rostedt
2014-08-13 14:43                 ` Paul E. McKenney
2014-08-13 16:30                   ` Peter Zijlstra
2014-08-13 16:43                     ` Jacob Pan
2014-08-13 18:24                       ` Paul E. McKenney
2014-08-13 16:35                   ` Peter Zijlstra
2014-08-13 18:25                     ` Paul E. McKenney
2014-08-13 14:43                 ` Peter Zijlstra
2014-08-13 20:56             ` Paul E. McKenney
2014-08-13 14:12           ` Paul E. McKenney
2014-08-13 14:42             ` Peter Zijlstra
2014-08-13 17:24               ` Peter Zijlstra
2014-08-13 17:30                 ` Peter Zijlstra
2014-08-13 18:16                 ` Peter Zijlstra
2014-08-13 18:20               ` Paul E. McKenney
2014-08-13 18:55                 ` Peter Zijlstra
2014-08-13 19:54                   ` Paul E. McKenney
2014-08-11 22:49   ` [PATCH v5 tip/core/rcu 16/16] rcu: Additional information on RCU-tasks stall-warning messages Paul E. McKenney
2014-08-14 20:46   ` [PATCH v5 tip/core/rcu 01/16] rcu: Add call_rcu_tasks() Pranith Kumar
2014-08-14 21:22     ` Paul E. McKenney
2014-08-12 23:57 ` [PATCH tip/core/rcu 0/16] RCU-tasks implementation 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=20140814225344.GB4752@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bobby.prani@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhart@linux.intel.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=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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.