public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Anton Blanchard <anton@au1.ibm.com>,
	Tim Pepper <lnxninja@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 10/15] nohz_task: Enter in extended quiescent state when in userspace
Date: Tue, 21 Dec 2010 18:20:40 -0800	[thread overview]
Message-ID: <20101222022040.GQ2143@linux.vnet.ibm.com> (raw)
In-Reply-To: <20101221214940.GV1750@nowhere>

On Tue, Dec 21, 2010 at 10:49:43PM +0100, Frederic Weisbecker wrote:
> On Tue, Dec 21, 2010 at 11:28:49AM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 20, 2010 at 04:24:17PM +0100, Frederic Weisbecker wrote:
> > > A nohz task can safely enter into extended quiescent state when
> > > it goes into userspace, this avoids a remote cpu to force the
> > > nohz task to be interrupted in order to notify quiescent states.
> > > 
> > > We enter into an extended quiescent state when:
> > > 
> > > - A nohz task resumes to userspace and is alone running on the
> > > CPU (we check if the local cpu is in nohz mode, which means
> > > no other task compete on that CPU). If the tick is still running
> > > then entering into extended QS will be done later from the second
> > > case:
> > > 
> > > - When the tick stops and verify the current task is a nohz one,
> > > is alone running on the CPU and runs in userspace.
> > > 
> > > We exit the extended quiescent state when:
> > > 
> > > - A nohz task enters the kernel and is alone running on the CPU.
> > > Again we check if the local cpu is in nohz mode for that. If
> > > the tick is still running then it means we are not in an extended
> > > QS and we don't do anything.
> > > 
> > > - The tick restarts because a new task is enqueued.
> > > 
> > > Whether the nohz task is in userspace or not is tracked by the
> > > per cpu nohz_task_ext_qs variable.
> > > 
> > > Architectures need to provide some backend to notify userspace
> > > exit/entry in order to support this mode.
> > > It needs to implement the TIF_NOHZ flag that switches to slow
> > > path syscall mode and to notify exceptions entry/exit.
> > > 
> > > We don't need to handle irqs or nmis as those are already handled
> > > by RCU through rcu_enter_irq/nmi helpers.
> > 
> > One question below...
> > 
> > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > > Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > Cc: Ingo Molnar <mingo@elte.hu>
> > > Cc: Steven Rostedt <rostedt@goodmis.org>
> > > Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Cc: Anton Blanchard <anton@au1.ibm.com>
> > > Cc: Tim Pepper <lnxninja@linux.vnet.ibm.com>
> > > ---
> > >  arch/Kconfig             |    4 +++
> > >  include/linux/tick.h     |   16 ++++++++++-
> > >  kernel/sched.c           |    3 ++
> > >  kernel/time/tick-sched.c |   61 +++++++++++++++++++++++++++++++++++++++++++++-
> > >  4 files changed, 81 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index e631791..d1ebea3 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -177,5 +177,9 @@ config HAVE_ARCH_JUMP_LABEL
> > > 
> > >  config HAVE_NO_HZ_TASK
> > >  	bool
> > > +	help
> > > +	  Features necessary hooks for a task wanting to enter nohz
> > > +	  while running alone on a CPU: thread flag for syscall hooks
> > > +	  and exceptions entry/exit hooks.
> > > 
> > >  source "kernel/gcov/Kconfig"
> > > diff --git a/include/linux/tick.h b/include/linux/tick.h
> > > index 7465a47..a704bb7 100644
> > > --- a/include/linux/tick.h
> > > +++ b/include/linux/tick.h
> > > @@ -8,6 +8,7 @@
> > > 
> > >  #include <linux/clockchips.h>
> > >  #include <linux/percpu-defs.h>
> > > +#include <asm/ptrace.h>
> > > 
> > >  #ifdef CONFIG_GENERIC_CLOCKEVENTS
> > > 
> > > @@ -130,10 +131,21 @@ extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
> > > 
> > >  #ifdef CONFIG_NO_HZ_TASK
> > >  DECLARE_PER_CPU(int, task_nohz_mode);
> > > +DECLARE_PER_CPU(int, nohz_task_ext_qs);
> > > +
> > > +extern void tick_nohz_task_enter_kernel(void);
> > > +extern void tick_nohz_task_exit_kernel(void);
> > > +extern void tick_nohz_task_enter_exception(struct pt_regs *regs);
> > > +extern void tick_nohz_task_exit_exception(struct pt_regs *regs);
> > >  extern int tick_nohz_task_mode(void);
> > > -#else
> > > +
> > > +#else /* !NO_HZ_TASK */
> > > +static inline void tick_nohz_task_enter_kernel(void) { }
> > > +static inline void tick_nohz_task_exit_kernel(void) { }
> > > +static inline void tick_nohz_task_enter_exception(struct pt_regs *regs) { }
> > > +static inline void tick_nohz_task_exit_exception(struct pt_regs *regs) { }
> > >  static inline int tick_nohz_task_mode(void) { return 0; }
> > > -#endif
> > > +#endif /* !NO_HZ_TASK */
> > > 
> > >  # else /* !NO_HZ */
> > >  static inline void tick_nohz_stop_sched_tick(int inidle) { }
> > > diff --git a/kernel/sched.c b/kernel/sched.c
> > > index b99f192..4412493 100644
> > > --- a/kernel/sched.c
> > > +++ b/kernel/sched.c
> > > @@ -2464,6 +2464,9 @@ static void nohz_task_cpu_update(void *unused)
> > >  	if (rq->nr_running > 1 || rcu_pending(cpu) || rcu_needs_cpu(cpu)) {
> > 
> > If the task enters a system call in nohz mode, and then that system call
> > enqueues an RCU callback, this code path will pull that CPU out of nohz
> > mode, right?
> > 
> > 							Thanx, Paul
> 
> Hmm, no because this code path is only called after rcu or the scheduler sends
> an IPI. And rcu won't call it after it enqueues a callback.
> 
> I did not think about that. If every other CPUs are in extended quiescent
> state, nobody will take care of the grace period comletion, unless we are
> lucky in the whole GP completion scenario. And at least the current CPU
> that enqueues the callbacks is supposed to take care of that grace period
> completion, right?
> 
> So I guess I need to restat the tick from there too.

Please!!!  ;-)

							Thanx, Paul

  reply	other threads:[~2010-12-22  2:20 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 15:24 [RFC PATCH 00/15] Nohz task support Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 01/15] nohz_task: New mask for cpus having nohz task Frederic Weisbecker
2010-12-24  8:00   ` Lai Jiangshan
2010-12-24  8:19     ` Dario Faggioli
2010-12-24 12:29       ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 02/15] nohz_task: Avoid nohz task cpu as non-idle timer target Frederic Weisbecker
2010-12-20 15:47   ` Peter Zijlstra
2010-12-20 16:06     ` Steven Rostedt
2010-12-20 16:12       ` Peter Zijlstra
2010-12-21  0:20         ` Frederic Weisbecker
2010-12-21  7:51           ` Peter Zijlstra
2010-12-21 13:58             ` Frederic Weisbecker
2010-12-21  0:13     ` Frederic Weisbecker
2010-12-21  7:50       ` Peter Zijlstra
2010-12-21 13:52         ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 03/15] nohz_task: Make tick stop and restart callable outside idle Frederic Weisbecker
2010-12-20 15:48   ` Peter Zijlstra
2010-12-20 16:19     ` Steven Rostedt
2010-12-20 16:25       ` Peter Zijlstra
2010-12-21  1:34         ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 04/15] nohz_task: Stop the tick when the nohz task runs alone Frederic Weisbecker
2010-12-20 15:51   ` Peter Zijlstra
2010-12-20 23:37     ` Frederic Weisbecker
2010-12-21  7:35       ` Peter Zijlstra
2010-12-21 13:22         ` Frederic Weisbecker
2010-12-21 14:34           ` Steven Rostedt
2010-12-21 15:14             ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 05/15] nohz_task: Restart the tick when another task compete on the cpu Frederic Weisbecker
2010-12-20 15:53   ` Peter Zijlstra
2010-12-20 23:39     ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 06/15] nohz_task: Keep the tick if rcu needs it Frederic Weisbecker
2010-12-20 15:58   ` Peter Zijlstra
2010-12-20 23:49     ` Frederic Weisbecker
2010-12-21  0:12       ` Jonathan Corbet
2010-12-21  2:10         ` Frederic Weisbecker
2010-12-21  8:10     ` Paul E. McKenney
2010-12-20 15:24 ` [RFC PATCH 07/15] nohz_task: Restart tick when RCU forces nohz task cpu quiescent state Frederic Weisbecker
2010-12-20 16:02   ` Peter Zijlstra
2010-12-20 23:52     ` Frederic Weisbecker
2010-12-21  7:41       ` Peter Zijlstra
2010-12-21 13:28         ` Frederic Weisbecker
2010-12-21 15:35         ` Paul E. McKenney
2010-12-20 15:24 ` [RFC PATCH 08/15] smp: Don't warn if irq are disabled but we don't wait for the ipi Frederic Weisbecker
2010-12-20 16:03   ` Peter Zijlstra
2010-12-21  0:02     ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 09/15] rcu: Make rcu_enter,exit_nohz() callable from irq Frederic Weisbecker
2010-12-21 19:26   ` Paul E. McKenney
2010-12-21 19:27     ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 10/15] nohz_task: Enter in extended quiescent state when in userspace Frederic Weisbecker
2010-12-20 16:18   ` Peter Zijlstra
2010-12-21  1:27     ` Frederic Weisbecker
2010-12-21  8:04       ` Peter Zijlstra
2010-12-21 14:06         ` Frederic Weisbecker
2010-12-21 19:28   ` Paul E. McKenney
2010-12-21 21:49     ` Frederic Weisbecker
2010-12-22  2:20       ` Paul E. McKenney [this message]
2010-12-20 15:24 ` [RFC PATCH 11/15] x86: Nohz task support Frederic Weisbecker
2010-12-20 16:23   ` Peter Zijlstra
2010-12-21  1:30     ` Frederic Weisbecker
2010-12-21  8:05       ` Peter Zijlstra
2010-12-21 14:19         ` Frederic Weisbecker
2010-12-21 15:12         ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 12/15] clocksource: Ignore nohz task cpu in clocksource watchdog Frederic Weisbecker
2010-12-20 16:27   ` Peter Zijlstra
2010-12-21  1:40     ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 13/15] sched: Protect nohz task cpu affinity Frederic Weisbecker
2010-12-20 16:28   ` Peter Zijlstra
2010-12-20 17:05     ` Steven Rostedt
2010-12-21  1:55       ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 14/15] nohz_task: Clear nohz task attribute on exit() Frederic Weisbecker
2010-12-20 16:30   ` Peter Zijlstra
2010-12-21  1:48     ` Frederic Weisbecker
2010-12-21  8:07       ` Peter Zijlstra
2010-12-21 14:22         ` Frederic Weisbecker
2010-12-20 15:24 ` [RFC PATCH 15/15] nohz_task: Procfs interface Frederic Weisbecker
2010-12-20 15:42   ` Peter Zijlstra
2010-12-20 15:57     ` Frederic Weisbecker
2010-12-20 16:16       ` Peter Zijlstra
2010-12-21  1:24         ` Frederic Weisbecker
2010-12-21  8:14           ` Peter Zijlstra
2010-12-21 14:00             ` Avi Kivity
2010-12-21 17:05               ` Frederic Weisbecker
2010-12-21 18:17                 ` Avi Kivity
2010-12-21 21:08                   ` Frederic Weisbecker
2010-12-22  9:22                     ` Avi Kivity
2010-12-22  9:51                       ` Peter Zijlstra
2010-12-22 20:41                         ` Frederic Weisbecker
2010-12-21 14:26             ` Frederic Weisbecker
2010-12-20 15:44 ` [RFC PATCH 00/15] Nohz task support Steven Rostedt
2010-12-20 23:33   ` Frederic Weisbecker
2010-12-21  1:36     ` Steven Rostedt
2010-12-21  2:15       ` Frederic Weisbecker
2010-12-21  7:34     ` Peter Zijlstra
2010-12-21 13:13       ` Frederic Weisbecker
2010-12-21 13:56     ` Avi Kivity
2010-12-21 17:01       ` Frederic Weisbecker
2010-12-20 16:35 ` Peter Zijlstra
2010-12-21  1:53   ` Frederic Weisbecker

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=20101222022040.GQ2143@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=anton@au1.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lnxninja@linux.vnet.ibm.com \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox