linux-kernel - Re: [PATCH tip/core/rcu 01/28] rcu: Simplify curing of load woes

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: <1307715512.3941.168.camel@twins>
Date:	Fri, 10 Jun 2011 16:18:32 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, josh@...htriplett.org,
	niv@...ibm.com, tglx@...utronix.de, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com, patches@...aro.org
Subject: Re: [PATCH tip/core/rcu 01/28] rcu: Simplify curing of load woes

On Wed, 2011-06-08 at 12:29 -0700, Paul E. McKenney wrote:
> Make the functions creating the kthreads wake them up.  Leverage the
> fact that the per-node and boost kthreads can run anywhere, thus
> dispensing with the need to wake them up once the incoming CPU has
> gone fully online.

Indeed, I failed to notice the node and boost threads weren't bound.

> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> ---
>  kernel/rcutree.c        |   65 +++++++++++++++-------------------------------
>  kernel/rcutree_plugin.h |   11 +-------
>  2 files changed, 22 insertions(+), 54 deletions(-)
> 
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index 4cc6a94..36e79d2 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -1634,6 +1634,20 @@ static int rcu_cpu_kthread(void *arg)
>   * to manipulate rcu_cpu_kthread_task.  There might be another CPU
>   * attempting to access it during boot, but the locking in kthread_bind()
>   * will enforce sufficient ordering.
> + *
> + * Please note that we cannot simply refuse to wake up the per-CPU
> + * kthread because kthreads are created in TASK_UNINTERRUPTIBLE state,
> + * which can result in softlockup complaints if the task ends up being
> + * idle for more than a couple of minutes.
> + *
> + * However, please note also that we cannot bind the per-CPU kthread to its
> + * CPU until that CPU is fully online.  We also cannot wait until the
> + * CPU is fully online before we create its per-CPU kthread, as this would
> + * deadlock the system when CPU notifiers tried waiting for grace
> + * periods.  So we bind the per-CPU kthread to its CPU only if the CPU
> + * is online.  If its CPU is not yet fully online, then the code in
> + * rcu_cpu_kthread() will wait until it is fully online, and then do
> + * the binding.
>   */
>  static int __cpuinit rcu_spawn_one_cpu_kthread(int cpu)
>  {
> @@ -1646,12 +1660,14 @@ static int __cpuinit rcu_spawn_one_cpu_kthread(int cpu)
>         t = kthread_create(rcu_cpu_kthread, (void *)(long)cpu, "rcuc%d", cpu);
>         if (IS_ERR(t))
>                 return PTR_ERR(t);
> -       kthread_bind(t, cpu);
> +       if (cpu_online(cpu))
> +               kthread_bind(t, cpu);
>         per_cpu(rcu_cpu_kthread_cpu, cpu) = cpu;
>         WARN_ON_ONCE(per_cpu(rcu_cpu_kthread_task, cpu) != NULL);
> -       per_cpu(rcu_cpu_kthread_task, cpu) = t;
>         sp.sched_priority = RCU_KTHREAD_PRIO;
>         sched_setscheduler_nocheck(t, SCHED_FIFO, &sp);
> +       per_cpu(rcu_cpu_kthread_task, cpu) = t;
> +       wake_up_process(t); /* Get to TASK_INTERRUPTIBLE quickly. */
>         return 0;
>  } 

I'm not quite seeing how this is working though, I cannot find any code
in rcu_cpu_kthread() that sets the thread affinity (not a hunk in this
patch that adds it).
--
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/