* [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
@ 2004-11-28 15:06 Oleg Nesterov
2004-11-28 14:43 ` William Lee Irwin III
2004-11-28 15:33 ` Dipankar Sarma
0 siblings, 2 replies; 6+ messages in thread
From: Oleg Nesterov @ 2004-11-28 15:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Dipankar Sarma, Manfred Spraul, Andrew Morton
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;
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
2004-11-28 15:06 [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr Oleg Nesterov
@ 2004-11-28 14:43 ` William Lee Irwin III
2004-11-28 15:01 ` Manfred Spraul
2004-11-28 16:12 ` Oleg Nesterov
2004-11-28 15:33 ` Dipankar Sarma
1 sibling, 2 replies; 6+ messages in thread
From: William Lee Irwin III @ 2004-11-28 14:43 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: linux-kernel, Dipankar Sarma, Manfred Spraul, Andrew Morton
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
2004-11-28 14:43 ` William Lee Irwin III
@ 2004-11-28 15:01 ` Manfred Spraul
2004-11-28 15:55 ` William Lee Irwin III
2004-11-28 16:12 ` Oleg Nesterov
1 sibling, 1 reply; 6+ messages in thread
From: Manfred Spraul @ 2004-11-28 15:01 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Oleg Nesterov, linux-kernel, Dipankar Sarma, Andrew Morton
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
2004-11-28 15:01 ` Manfred Spraul
@ 2004-11-28 15:55 ` William Lee Irwin III
0 siblings, 0 replies; 6+ messages in thread
From: William Lee Irwin III @ 2004-11-28 15:55 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Oleg Nesterov, linux-kernel, Dipankar Sarma, Andrew Morton
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
2004-11-28 14:43 ` William Lee Irwin III
2004-11-28 15:01 ` Manfred Spraul
@ 2004-11-28 16:12 ` Oleg Nesterov
1 sibling, 0 replies; 6+ messages in thread
From: Oleg Nesterov @ 2004-11-28 16:12 UTC (permalink / raw)
To: William Lee Irwin III
Cc: linux-kernel, Dipankar Sarma, Manfred Spraul, Andrew Morton
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
2004-11-28 15:06 [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr Oleg Nesterov
2004-11-28 14:43 ` William Lee Irwin III
@ 2004-11-28 15:33 ` Dipankar Sarma
1 sibling, 0 replies; 6+ messages in thread
From: Dipankar Sarma @ 2004-11-28 15:33 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: linux-kernel, Manfred Spraul, Andrew Morton
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-28 15:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-28 15:06 [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr Oleg Nesterov
2004-11-28 14:43 ` William Lee Irwin III
2004-11-28 15:01 ` Manfred Spraul
2004-11-28 15:55 ` William Lee Irwin III
2004-11-28 16:12 ` Oleg Nesterov
2004-11-28 15:33 ` Dipankar Sarma
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®