lkml.org 
[lkml]   [2004]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] rcu: eliminate rcu_data.last_qsctr
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.042 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site