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

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

[William Lee Irwin III]

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.


-- wli

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
>  
>

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

[Oleg Nesterov]

Hello.

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.

Oleg.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

--- 2.6.10-rc2/include/linux/rcupdate.h~	2004-11-27 21:32:49.000000000 +0300
+++ 2.6.10-rc2/include/linux/rcupdate.h	2004-11-28 18:59:40.349288512 +0300
@@ -88,8 +88,6 @@ struct rcu_data {
 	/* 1) quiescent state handling : */
 	long		quiescbatch;     /* Batch # for grace period */
 	long		qsctr;		 /* User-mode/idle loop etc. */
-	long            last_qsctr;	 /* value of qsctr at beginning */
-					 /* of rcu grace period */
 	int		qs_pending;	 /* core waits for quiesc state */
 
 	/* 2) batch handling */
--- 2.6.10-rc2/kernel/rcupdate.c~	2004-11-28 17:29:19.084446040 +0300
+++ 2.6.10-rc2/kernel/rcupdate.c	2004-11-28 20:01:29.417424448 +0300
@@ -215,9 +215,9 @@ static void rcu_check_quiescent_state(st
 			struct rcu_state *rsp, struct rcu_data *rdp)
 {
 	if (rdp->quiescbatch != rcp->cur) {
-		/* new grace period: record qsctr value. */
+		/* new grace period: reset qsctr value. */
 		rdp->qs_pending = 1;
-		rdp->last_qsctr = rdp->qsctr;
+		rdp->qsctr = 0;
 		rdp->quiescbatch = rcp->cur;
 		return;
 	}
@@ -229,7 +229,7 @@ static void rcu_check_quiescent_state(st
 	if (!rdp->qs_pending)
 		return;
 
-	if (rdp->qsctr == rdp->last_qsctr)
+	if (rdp->qsctr == 0)
 		return;
 	rdp->qs_pending = 0;

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

[Dipankar Sarma]

On Sun, Nov 28, 2004 at 06:06:55PM +0300, Oleg Nesterov wrote:
> Hello.
> 
> 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.
> 

No race with interrupt for rdp->qsctr, so it looks good.

Thanks
Dipankar

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

[William Lee Irwin III]

William Lee Irwin III wrote:
>> 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.

On Sun, Nov 28, 2004 at 04:01:43PM +0100, Manfred Spraul wrote:
> 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.

Looks like if I ever knew what was going on in rcupdate.c I forgot it.
Back to damage control for ongoing catastrophes for me.


-- wli

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

[Oleg Nesterov]

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.

How can it be?

Afaics, the whole rcu_data is cpu local.

If i am wrong, could you please clarify?

Oleg.