Messages in this thread | | | Date | Sat, 27 Nov 2004 18:56:08 +0100 | From | Manfred Spraul <> | Subject | Re: PATCH? rcu: eliminate rcu_ctrlblk.lock |
| |
Oleg Nesterov wrote:
>Hello. > >I am trying to understand the rcu implementetion. > >I can't understand why rcu_ctrlblk.seqcount is needed. >It seems to me it can be replaced by a couple of barriers. > > >
Your patch would add one new corner case:
start: next_pending==1. rcp->cur == 11. cpu 1: rcu_start_back sets next_pending to 0. cpu 2: rdp->batch = rcp->cur + 1 [i.e. wait for end of period 12] cpu 2: notices next_pending == 0, tries to acquire the spinlock [blocks] cpu 1: rcp->cur++ [i.e. start period 12] cpu 1: releases the spinlock cpu 2: gets the spinlock, sets next_pending to 1 and exits.
Now next_pending is 1 [i.e. at the end of grace period 12 grace period 13 is automatically started], although noone has callbacks waiting for period 13.
This is not fatal: the combination is rare, so perhaps we could tolerate the race. But on the other hand the sequence locks are outside of the hot paths and not much slower than a smp_rmb().
Dipankar - what do you think?
-- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |