On Wed, Oct 22, 2008 at 08:41:11PM +0200, Manfred Spraul wrote:
quoted text
> 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
--
unsubscribe notice
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/