Re: Final per cpu consistency patch for -next or late in 3.19 merge period

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- Original Message -----
> From: "Tejun Heo" <htejun@gmail.com>
> To: "Christoph Lameter" <cl@linux.com>
> Cc: linux-kernel@vger.kernel.org, "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>, "Andrew Morton"
> <akpm@linux-foundation.org>
> Sent: Tuesday, December 2, 2014 12:11:02 PM
> Subject: Re: Final per cpu consistency patch for -next or late in 3.19 merge period
> 
> On Tue, Dec 02, 2014 at 10:57:50AM -0600, Christoph Lameter wrote:
> > On Tue, 2 Dec 2014, Tejun Heo wrote:
> > 
> > > Can you please update Documentation/local_ops.txt and comments which
> > > contain __get_cpu_var() and send the updated patch to Andrew?
> > 
> > Owww.... local_* ops are exotic operations that should no longer be
> > regularly used. This_cpu ops create less overhead and
> > are simpler to use. Lets merge the prior patch as is and then add this
> > documentation patch which may cause some additional discussion.
> 
> Sure, I just wanna make sure we don't have dangling references to
> __get_cpu_var() which no longer exists.  There are also a couple
> places where comment text refers to it.  Let's please take care of
> them too.

If I understand correctly, __get_cpu_var() is being deprecated ?
If this_cpu_ptr() is semantically equivalent to __get_cpu_var(), we can do a
wrapper in lttng-modules and move to the new name, no worries there.

Background:

LTTng-modules (out of tree) still uses __get_cpu_var() for our per-cpu
nesting counter (internal safety net), and our per-cpu last_tsc value
tracking since 3.17.

We also rely on local_t atomic operations to interact with each per-cpu
ring buffer. Since we already need to get the CPU number to know which
dynamically allocated ring buffer we need to work with, and since we're
always in preempt disabled context, there is not much gain in changing
the entire design to move from local_t ops to this_cpu() ops.

Thanks,

Mathieu


> 
> Thanks.
> 
> --
> tejun
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com