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 <[email protected]>
--- 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;
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
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
>
>
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.
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
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