lkml.org 
[lkml]   [2014]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2014-08-01 21:21    [W:0.120 / U:1.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site