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

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

[Christoph Lameter]

This is the final patch to remove __get_cpu_var. I checked -next and there
are no remaining uses of __get_cpu_var. So either merge this to -next or
wait until 3.19 late.

However, if we wait till 3.19 then I may have to do another pass if
people add more uses of __get_cpu_var and submit another patch.

From: Christoph Lameter <cl@linux.com>
Date: Tue, 29 Jul 2014 16:09:54 -0500
Subject: [PATCH] Remove __get_cpu_var and __raw_get_cpu_var macros

No user is left in the kernel source tree. Therefore we can
drop the definitions.

This is the final merge of the transition away from __get_cpu_var.
After this patch the kernel will not build if anyone uses __get_cpu_var.

Signed-off-by: Christoph Lameter <cl@linux.com>
---
 include/asm-generic/percpu.h | 5 -----
 1 file changed, 5 deletions(-)

Index: linux/include/linux/percpu-defs.h
===================================================================
--- linux.orig/include/linux/percpu-defs.h
+++ linux/include/linux/percpu-defs.h
@@ -254,8 +254,6 @@ do {									\
 #endif	/* CONFIG_SMP */

 #define per_cpu(var, cpu)	(*per_cpu_ptr(&(var), cpu))
-#define __raw_get_cpu_var(var)	(*raw_cpu_ptr(&(var)))
-#define __get_cpu_var(var)	(*this_cpu_ptr(&(var)))

 /*
  * Must be an lvalue. Since @var must be a simple identifier,

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

[Tejun Heo]

Hello, Christoph.

On Fri, Nov 28, 2014 at 12:31:22PM -0600, Christoph Lameter wrote:
> This is the final patch to remove __get_cpu_var. I checked -next and there
> are no remaining uses of __get_cpu_var. So either merge this to -next or
> wait until 3.19 late.
> 
> However, if we wait till 3.19 then I may have to do another pass if
> people add more uses of __get_cpu_var and submit another patch.
> 
> From: Christoph Lameter <cl@linux.com>
> Date: Tue, 29 Jul 2014 16:09:54 -0500
> Subject: [PATCH] Remove __get_cpu_var and __raw_get_cpu_var macros
> 
> No user is left in the kernel source tree. Therefore we can
> drop the definitions.
> 
> This is the final merge of the transition away from __get_cpu_var.
> After this patch the kernel will not build if anyone uses __get_cpu_var.

Can you please update Documentation/local_ops.txt and comments which
contain __get_cpu_var() and send the updated patch to Andrew?

Andrew, this is removal of the two deprecated per-cpu accessors.  All
the existing users are gone from the devel branches and thus from -mm.
Can you please route this once Christoph posts an updated version?

Thanks.

-- 
tejun

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

[Christoph Lameter]

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.




From: Christoph Lameter <cl@linux.com>
Subject: [PATCH] Update local_ops.txt to reflect this_cpu operations

Update the documentation to reflect changes due to the availability
of this_cpu operations.

Signed-off-by: Christoph Lameter <cl@linux.com>
---
 include/asm-generic/percpu.h | 5 -----
 1 file changed, 5 deletions(-)

Index: linux/Documentation/local_ops.txt
===================================================================
--- linux.orig/Documentation/local_ops.txt
+++ linux/Documentation/local_ops.txt
@@ -8,6 +8,11 @@ to implement them for any given architec
 properly. It also stresses on the precautions that must be taken when reading
 those local variables across CPUs when the order of memory writes matters.

+Note that local_t based operations are not recommended for general kernel use.
+Please use the this_cpu operations instead unless there is really a special purpose.
+Most uses of local_t in the kernel have been replaced by this_cpu operations.
+this_cpu operations combine the relocation with the local_t like semantics in
+a single instruction and yield more compact and faster executing code.


 * Purpose of local atomic operations
@@ -87,10 +92,10 @@ the per cpu variable. For instance :
 	local_inc(&get_cpu_var(counters));
 	put_cpu_var(counters);

-If you are already in a preemption-safe context, you can directly use
-__get_cpu_var() instead.
+If you are already in a preemption-safe context, you can use
+this_cpu_ptr() instead.

-	local_inc(&__get_cpu_var(counters));
+	local_inc(this_cpu_ptr(&counters));



@@ -134,7 +139,7 @@ static void test_each(void *info)
 {
 	/* Increment the counter from a non preemptible context */
 	printk("Increment on cpu %d\n", smp_processor_id());
-	local_inc(&__get_cpu_var(counters));
+	local_inc(this_cpu_ptr(&counters));

 	/* This is what incrementing the variable would look like within a
 	 * preemptible context (it disables preemption) :

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

[Tejun Heo]

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.

Thanks.

-- 
tejun

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

[Mathieu Desnoyers]

----- 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

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

[Christoph Lameter]

On Tue, 2 Dec 2014, Mathieu Desnoyers wrote:

> If I understand correctly, __get_cpu_var() is being deprecated ?

Its gone in -next.

> 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.

Sure. Look at the conversion descriptions.

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

[Christoph Lameter]

On Tue, 2 Dec 2014, Tejun Heo wrote:

> 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.

Here is the ia64 patch:


From: Christoph Lameter <cl@linux.com>
Subject: ia64: Update comment that references __get_cpu_var

__get_cpu_var was removed. Update the comments.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Christoph Lameter <cl@linux.com>

Index: linux/arch/ia64/include/asm/percpu.h
===================================================================
--- linux.orig/arch/ia64/include/asm/percpu.h
+++ linux/arch/ia64/include/asm/percpu.h
@@ -35,8 +35,8 @@ extern void *per_cpu_init(void);

 /*
  * Be extremely careful when taking the address of this variable!  Due to virtual
- * remapping, it is different from the canonical address returned by __get_cpu_var(var)!
- * On the positive side, using __ia64_per_cpu_var() instead of __get_cpu_var() is slightly
+ * remapping, it is different from the canonical address returned by this_cpu_ptr(&var)!
+ * On the positive side, using __ia64_per_cpu_var() instead of this_cpu_ptr() is slightly
  * more efficient.
  */
 #define __ia64_per_cpu_var(var) (*({					\

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

[Luck, Tony]

> From: Christoph Lameter <cl@linux.com>
> Subject: ia64: Update comment that references __get_cpu_var
>
> __get_cpu_var was removed. Update the comments.

Applied.  Will send to Linus towards the end of the merge window

Thanks

-Tony

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

[Christoph Lameter]

On Tue, 2 Dec 2014, Tejun Heo wrote:

> 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.

And the last one: PARISC


From: Christoph Lameter <cl@linux.com>
Subject: parisc: Update comments refereing to __get_cpu_var

__get_cpu_var was removed. Update comments to refer to
this_cpu_ptr() instead.

Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Signed-off-by: Christoph Lameter <cl@linux.com>

Index: linux/arch/parisc/lib/fixup.S
===================================================================
--- linux.orig/arch/parisc/lib/fixup.S
+++ linux/arch/parisc/lib/fixup.S
@@ -38,14 +38,14 @@
 	LDREGX \t2(\t1),\t2
 	addil LT%exception_data,%r27
 	LDREG RT%exception_data(%r1),\t1
-	/* t1 = &__get_cpu_var(exception_data) */
+	/* t1 = this_cpu_ptr(&exception_data) */
 	add,l \t1,\t2,\t1
 	/* t1 = t1->fault_ip */
 	LDREG EXCDATA_IP(\t1), \t1
 	.endm
 #else
 	.macro  get_fault_ip t1 t2
-	/* t1 = &__get_cpu_var(exception_data) */
+	/* t1 = this_cpu_ptr(&exception_data) */
 	addil LT%exception_data,%r27
 	LDREG RT%exception_data(%r1),\t2
 	/* t1 = t2->fault_ip */