lkml.org 
[lkml]   [2008]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH, RFC] v7 scalable classic RCU implementation
On Wed, Oct 22, 2008 at 08:41:11PM +0200, Manfred Spraul wrote:
> Paul E. McKenney wrote:
>> Only once per such CPU every grace period -- seems in the noise to me.
>> But I should revisit, as I have changed things quite a bit since I
>> made that decision many weeks ago. ;-)
>>
>>
> Another small point:
> Does your implementation support rcu_check_callbacks() with cpu !=
> smp_processor_id()?
> I don't think my locking would support it properly.
> Thus:
> - cpu != smp_processor_id() doesn't work.
> - stack space for a useless parameter.
> - the explicit cpu parameter prevents the rcu code from using
> get_cpu_var().
>
> What about modifying the rcu_check_callbacks() prototype? I'd propose to
> remove the cpu parameter.

That would work fine for rcutree.c. If I were to invoke
rcu_check_callbacks() remotely, I would use something like
smp_call_function() to make it happen.

Hmmm... Looks like rcu_pending is also always called with its cpu
parameter set to the current CPU, and same for rcu_needs_cpu().
And given that all the external uses of rcu_check_callbacks() are
of the following form:

if (rcu_pending(cpu))
rcu_check_callbacks(cpu, whatever);


perhaps rcu_pending() should be an internal-to-RCU API invoked from
rcu_check_callbacks().

Thoughts?

Thanx, Paul


\
 
 \ /
  Last update: 2008-10-22 23:05    [W:0.206 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site