Messages in this thread | | | Subject | Re: [PATCH RFC tip/core/rcu 11/11] rcu: move TREE_RCU from softirq to kthread | From | Peter Zijlstra <> | Date | Mon, 28 Feb 2011 10:47:17 +0100 |
| |
On Mon, 2011-02-28 at 11:29 +0800, Lai Jiangshan wrote: > >>> +static int rcu_cpu_kthread_should_stop(int cpu) > >>> +{ > >>> + while (cpu_is_offline(cpu) || smp_processor_id() != cpu) { > >>> + if (kthread_should_stop()) > >>> + return 1; > >>> + local_bh_enable(); > >>> + schedule_timeout_uninterruptible(1); > >>> + if (smp_processor_id() != cpu) > >>> + set_cpus_allowed_ptr(current, cpumask_of(cpu)); > >> > >> The current task is PF_THREAD_BOUND, > >> Why do "set_cpus_allowed_ptr(current, cpumask_of(cpu));" ? > > > > Because I have seen CPU hotplug operations unbind PF_THREAD_BOUND threads.
Correct, but that's on unplug, the rest of the story seems about plug, so just detatch the thread on down/offline and let it die when its done.
> > In addition, I end up having to spawn the kthread at CPU_UP_PREPARE time,
Sure, that's a common time to create such treads :-), you can kthread_ceate()+kthread_bind() in UP_PREPARE, just don't wake them yet.
> > at which point the thread must run unbound because its CPU isn't online > > yet. I cannot invoke kthread_create() within the stop-machine handler > > (right?).
No you can not ;-)
> I cannot wait until CPU_ONLINE time because that results in > > hangs when other CPU notifiers wait for grace periods. > > > > Yes, I did find out about the hangs the hard way. Why do you ask? ;-)
Right, so I assume that whoever needs the thread will:
1) wake the thread, 2) only do so after the cpu is actually online, how else could it be executing code? :-)
| |