lkml.org 
[lkml]   [2009]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2009-10-15 09:53    [W:2.096 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site