Messages in this thread | | | Date | Fri, 1 Aug 2014 20:40:59 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v3 tip/core/rcu 1/9] rcu: Add call_rcu_tasks() |
| |
On 08/01, Paul E. McKenney wrote: > > On Fri, Aug 01, 2014 at 04:11:44PM +0200, Oleg Nesterov wrote: > > Not sure this makes any sense, but perhaps we can check for the new > > callbacks and start the next gp. IOW, the main loop roughly does > > > > for (;;) { > > list = rcu_tasks_cbs_head; > > rcu_tasks_cbs_head = NULL; > > > > if (!list) > > sleep(); > > > > synchronize_sched(); > > > > wait_for_rcu_tasks_holdout(); > > > > synchronize_sched(); > > > > process_callbacks(list); > > } > > > > we can "join" 2 synchronize_sched's and do > > > > ready_list = NULL; > > for (;;) { > > list = rcu_tasks_cbs_head; > > rcu_tasks_cbs_head = NULL; > > > > if (!list && !ready_list) > > sleep(); > > > > synchronize_sched(); > > > > if (ready_list) { > > process_callbacks(ready_list); > > ready_list = NULL; > > } > > > > if (!list) > > continue; > > > > wait_for_rcu_tasks_holdout(); > > ready_list = list; > > } > > The lack of barriers for the updates I am checking mean that I really > do need a synchronize_sched() on either side of the grace-period wait.
Yes,
> The grace period needs to guarantee that anything that happened on any > CPU before the start of the grace period happens before anything that > happens on any CPU after the end of the grace period. If I leave off > either synchronize_sched(), we lose this guarantee.
But the 2nd variant still has synchronize_sched() on both sides?
Oleg.
| |