Messages in this thread | | | Date | Wed, 30 Jul 2014 09:08:12 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC tip/core/rcu 1/9] rcu: Add call_rcu_tasks() |
| |
On Wed, Jul 30, 2014 at 05:49:49PM +0200, Oleg Nesterov wrote: > On 07/28, Paul E. McKenney wrote: > > > > This commit adds a new RCU-tasks flavor of RCU, which provides > > call_rcu_tasks(). This RCU flavor's quiescent states are voluntary > > context switch (not preemption!), userspace execution, and the idle loop. > > Note that unlike other RCU flavors, these quiescent states occur in tasks, > > not necessarily CPUs. Includes fixes from Steven Rostedt. > > I still hope I will read this series later. Not that I really hope I will > understand it ;)
Well, don't put too much time into it just now. Bozo here has been doing concurrent programming so long that he sometimes misses opportunities for single-threaded programming. Hence the locked-list stuff. :-/
> Just one question for now, > > > +static int __noreturn rcu_tasks_kthread(void *arg) > > +{ > > + unsigned long flags; > > + struct task_struct *g, *t; > > + struct rcu_head *list; > > + struct rcu_head *next; > > + > > + /* FIXME: Add housekeeping affinity. */ > > + > > + /* > > + * Each pass through the following loop makes one check for > > + * newly arrived callbacks, and, if there are some, waits for > > + * one RCU-tasks grace period and then invokes the callbacks. > > + * This loop is terminated by the system going down. ;-) > > + */ > > + for (;;) { > > + > > + /* Pick up any new callbacks. */ > > + raw_spin_lock_irqsave(&rcu_tasks_cbs_lock, flags); > > + smp_mb__after_unlock_lock(); /* Enforce GP memory ordering. */ > > + list = rcu_tasks_cbs_head; > > + rcu_tasks_cbs_head = NULL; > > + rcu_tasks_cbs_tail = &rcu_tasks_cbs_head; > > + raw_spin_unlock_irqrestore(&rcu_tasks_cbs_lock, flags); > > + > > + /* If there were none, wait a bit and start over. */ > > + if (!list) { > > + schedule_timeout_interruptible(HZ); > > + flush_signals(current); > > Why? And I see more flush_signals() in the current kernel/rcu/ code. Unless > a kthread does allow_signal() it can't have a pending signal?
Because I am overly paranoid. ;-)
Thanx, Paul
| |