Re: [my_cpu_ptr 1/5] Introduce my_cpu_ptr()
From: Christoph Lameter
Date: Fri May 29 2009 - 11:38:20 EST
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
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
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
that will require an irq off / on on some platforms and be a simple
increment on others.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/