Messages in this thread | | | Subject | Re: [PATCH 3/4 V2] implement per-domain single-thread state machine call_srcu() | From | Peter Zijlstra <> | Date | Sat, 14 Apr 2012 15:22:10 +0200 |
| |
On Tue, 2012-04-10 at 16:18 -0700, Paul E. McKenney wrote: > > +static void srcu_invoke_callbacks(struct srcu_struct *sp) > > +{ > > + int i; > > + struct rcu_head *head; > > + > > + for (i = 0; i < SRCU_CALLBACK_BATCH; i++) { > > If there really can be thousands of callbacks dumped into SRCU, a more > adaptive strategy might be needed. In the meantime, I am hoping that > the fact that the workqueue is retriggered in this case suffices. > > Note that this function is preemptible, so there is less penalty for > running a very long batch.
With just the ->func() invocation below non-preemptible, I really don't see a point in having this loop limit.
> Which reminds me... An srcu_struct structure with a large pile of > SRCU callbacks won't react very quickly in response to an invocation of > synchronize_srcu_expedited(). This is why the other RCU implementations > have a non-callback codepath for expedited grace periods. > > Or am I missing something here?
I would suggest adding that extra complexity when we need it ;-)
> > + head = rcu_batch_dequeue(&sp->batch_done); > > + if (!head) > > + break; > > + head->func(head); > > I have surrounded this with local_bh_disable() and local_bh_enable() > in order to enforce the no-sleeping-in-callbacks rule. Please let me > know if I missed some other enforcement mechanism.
Is that -rt inspired hackery? Otherwise I would simply suggest preempt_disable/enable(), they do pretty much the same and are less confusing.
> > + }
| |