linux-kernel - Re: [PATCH 03/10] rcu: Kick full dynticks CPU on extended grace period with a void IRQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140721181612.GJ8690@linux.vnet.ibm.com>
Date:	Mon, 21 Jul 2014 11:16:12 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH 03/10] rcu: Kick full dynticks CPU on extended grace
 period with a void IRQ

On Sat, Jul 19, 2014 at 02:44:14AM +0200, Frederic Weisbecker wrote:
> When a full dynticks CPU stays for too long in the kernel, it may fail
> to report quiescent states due to it missing ticks and therefore it can
> delay the completion of grace periods.
> 
> A way to solve this is to send an IPI to the incriminated CPU such that
> it can check rcu_needs_cpu() and reschedule some ticks accordingly to
> poll again on quiescent states reports.
> 
> This is what we try to achieve while calling rcu_kick_nohz_cpu() but it
> has no effect because we trigger a scheduler IPI which is actually a
> no-op when not used for scheduler internal purpose, ie: it doesn't call
> irq_exit() when not used for remote wakeup or other specifics.
> 
> No need to tweak the scheduler IPI further though. Lets keep it clean
> of external noise and use an empty IPI instead. We hereby get sure that
> we will call irq_exit() on the target without much overhead nor added
> noise on scheduler fast path.
> 
> Cc: Ingo Molnar <mingo@...nel.org>
> Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Viresh Kumar <viresh.kumar@...aro.org>
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>

Reviewed-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>

> ---
>  kernel/rcu/tree_plugin.h | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index cbc2c45..395c14d 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2401,14 +2401,16 @@ static bool init_nocb_callback_list(struct rcu_data *rdp)
>   * off.  RCU will be paying attention to this CPU because it is in the
>   * kernel, but the CPU cannot be guaranteed to be executing the RCU state
>   * machine because the scheduling-clock tick has been disabled.  Therefore,
> - * if an adaptive-ticks CPU is failing to respond to the current grace
> - * period and has not be idle from an RCU perspective, kick it.
> + * if an full dynticks CPU is failing to respond to the current grace
> + * period and has not be idle from an RCU perspective, kick it with a
> + * void IRQ so that it can check that RCU needs its tick from rcu_needs_cpu()
> + * on irq exit.
>   */
>  static void rcu_kick_nohz_cpu(int cpu)
>  {
>  #ifdef CONFIG_NO_HZ_FULL
>  	if (tick_nohz_full_cpu(cpu))
> -		smp_send_reschedule(cpu);
> +		irq_work_void_on(cpu);
>  #endif /* #ifdef CONFIG_NO_HZ_FULL */
>  }
> 
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/