Messages in this thread | | | Date | Thu, 15 Oct 2009 16:47:44 +0900 | From | Tejun Heo <> | Subject | Re: [this_cpu_xx V6 3/7] Use this_cpu operations in slub |
| |
Christoph Lameter wrote: > On Wed, 14 Oct 2009, Tejun Heo wrote: > >>> __this_cpu_ptr could be converted to this_cpu_ptr but I think the __ are >>> useful there too to show that we are in a preempt section. >> That doesn't make much sense. __ for this_cpu_ptr() means "bypass >> sanity check, we're knowingly violating the required conditions" not >> "we know sanity checks will pass here". > > Are you defining what __ means for this_cpu_ptr?
I was basically stating the different between raw_smp_processor_id() and smp_processor_id() which I thought applied the same to __this_cpu_ptr() and this_cpu_ptr().
>>> The calls to raw_smp_processor_id and smp_processor_id() are only useful >>> in the fallback case. There is no need for those if the arch has a way to >>> provide the current percpu offset. So we in effect have two meanings of __ >>> right now. >>> >>> 1. We do not care about the preempt state (thus we call >>> raw_smp_processor_id so that the preempt state does not trigger) >>> >>> 2. We do not need to disable preempt before the operation. >>> >>> __this_cpu_ptr only implies 1. __this_cpu_add uses 1 and 2. >> >> Yeah, we need to clean it up. The naming is too confusing. > > Its consistent if __ means both 1 and 2. If we want to distinguish it then > we may want to create raw_this_cpu_xx which means that we do not call > smp_processor_id() on fallback but raw_smp_processor_id(). Does not > matter if the arch provides a per cpu offset. > > This would mean duplicating all the macros. The use of raw_this_cpu_xx > should be rare so maybe the best approach is to say that __ means only > that the macro does not need to disable preempt but it still checks for > preemption being off. Then audit the __this_cpu_xx uses and see if there > are any that require a raw_ variant. > > The vm event counters require both no check and no preempt since they can > be implemented in a racy way.
The biggest grief I have is that the meaning of __ is different among different accessors. If that can be cleared up, we would be in much better shape without adding any extra macros. Can we just remove all __'s and use meaningful pre or suffixes like raw or irq or whatever?
Thanks.
-- tejun
| |