[lkml]   [2009]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [my_cpu_ptr 1/5] Introduce my_cpu_ptr()
    On Fri, 29 May 2009, Rusty Russell wrote:

    > > Have not seen it but it would be a bit confusing since
    > > we already have get_cpu* which must be paired with put_cpu*
    > > because of the refcount taking (get_cpu_var and get_cpu).
    > > get_cpu_ptr() would not have to be paired.
    > To clarify, get_cpu_ptr() would be paired with put_cpu_ptr(). __get_cpu_ptr()
    > would be the "raw" one:
    > #define get_cpu_ptr(xx) per_cpu_ptr(xx, get_cpu())
    > #define __get_cpu_ptr(xx) per_cpu_ptr(xx, smp_processor_id())

    Hmmm.. That would be a major change in semantics. I tend to
    think about these ops more as atomic like operations rather than preempt
    sections. The operation to obtain a the current instance for a given
    processor is an operation done in a given preemption context. The
    get_cpu_ptr() approach establishes the preemption context during the same

    That would mean use


    instead of


    And for context in which we know that preemption is off




    So its the same

    How would that look for atomic per cpu ops?




    and known preemption off context



    Same again

    Seems to be added complexity to also push a change of preemption into
    these operations. I'd rather keep the preempt status unchanged by these
    operations in particular because some counters may need interrupt
    protection on some platforms and not on others. We will likely need some
    additional operations like

    this_cpu_inc_irqsafe( ....)

    that will require an irq off / on on some platforms and be a simple
    increment on others.

     \ /
      Last update: 2009-05-29 17:41    [W:0.022 / U:58.408 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site