Re: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr

[Manfred Spraul]

William Lee Irwin III wrote:

> On Sun, Nov 28, 2004 at 06:06:55PM +0300, Oleg Nesterov wrote:
>  
>
> > Is the rcu_data.last_qsctr really needed?
> > It is used in rcu_check_quiescent_state() exclusively.
> > I think we can reset qsctr at the start of the grace period,
> > and then just test qsctr against 0.
> >    
>
> That might work if there were only 1 cpu. The local cpu owns ->qsctr,
> ->last_qsctr is stored and loaded by remote cpus under locks.
>
>  
No. The whole rcu_data structure is cpu-local, it's never accessed from 
remote cpus [except during hotunplug]. It doesn't even contain a lock.
A grace period consists of the following steps:
- one cpu is in rcu_start_batch() and does rcp->cur++.
- for all cpus:
* __rcu_pending mismatch between rdp->quiescbatch and rcp->cur, calls to 
rcu_check_callbacks
* rcu_check_callbacks schedules rcu_process_callbacks as a tasklet
* rcu_process_callbacks stores last_qsctr.
* further calls to rcu_process_callbacks du to __rcu_pendig()==1, until 
qsctr was increased
* grace period completed by the cpu
- for the last cpu: call rcu_start_batch() and start the next one, if 
needed.

As far as I can see the patch is correct.

--
   Manfred
-

> -- wli
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/