Messages in this thread | | | Date | Wed, 22 Oct 2008 14:02:54 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [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
| |