[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK5ve-JV3vC++RdUaore6ievOcv4UsNd9hrVq4h_5HaCQdGO+Q@mail.gmail.com>
Date: Tue, 3 Sep 2013 13:40:27 -0700
From: Bryan Wu <cooloney@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: Tejun Heo <tj@...nel.org>, akpm@...uxfoundation.org,
linux-arch@...r.kernel.org, Steven Rostedt <srostedt@...hat.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [gcv v3 18/35] drivers/leds: Replace __get_cpu_var uses
On Wed, Aug 28, 2013 at 12:48 PM, Christoph Lameter <cl@...ux.com> wrote:
> __get_cpu_var() is used for multiple purposes in the kernel source. One of them is
> address calculation via the form &__get_cpu_var(x). This calculates the address for
> the instance of the percpu variable of the current processor based on an offset.
>
> Other use cases are for storing and retrieving data from the current processors percpu area.
> __get_cpu_var() can be used as an lvalue when writing data or on the right side of an assignment.
>
> __get_cpu_var() is defined as :
>
>
> #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
>
>
>
> __get_cpu_var() always only does an address determination. However, store and retrieve operations
> could use a segment prefix (or global register on other platforms) to avoid the address calculation.
>
> this_cpu_write() and this_cpu_read() can directly take an offset into a percpu area and use
> optimized assembly code to read and write per cpu variables.
>
>
> This patch converts __get_cpu_var into either an explicit address calculation using this_cpu_ptr()
> or into a use of this_cpu operations that use the offset. Thereby address calcualtions are avoided
> and less registers are used when code is generated.
>
> At the end of the patchset all uses of __get_cpu_var have been removed so the macro is removed too.
>
> The patchset includes passes over all arches as well. Once these operations are used throughout then
> specialized macros can be defined in non -x86 arches as well in order to optimize per cpu access by
> f.e. using a global register that may be set to the per cpu base.
>
>
>
>
> Transformations done to __get_cpu_var()
>
>
> 1. Determine the address of the percpu instance of the current processor.
>
> DEFINE_PER_CPU(int, y);
> int *x = &__get_cpu_var(y);
>
> Converts to
>
> int *x = this_cpu_ptr(&y);
>
>
> 2. Same as #1 but this time an array structure is involved.
>
> DEFINE_PER_CPU(int, y[20]);
> int *x = __get_cpu_var(y);
>
> Converts to
>
> int *x = this_cpu_ptr(y);
>
>
> 3. Retrieve the content of the current processors instance of a per cpu variable.
>
> DEFINE_PER_CPU(int, u);
> int x = __get_cpu_var(y)
>
> Converts to
>
> int x = __this_cpu_read(y);
>
>
> 4. Retrieve the content of a percpu struct
>
> DEFINE_PER_CPU(struct mystruct, y);
> struct mystruct x = __get_cpu_var(y);
>
> Converts to
>
> memcpy(this_cpu_ptr(&x), y, sizeof(x));
>
>
> 5. Assignment to a per cpu variable
>
> DEFINE_PER_CPU(int, y)
> __get_cpu_var(y) = x;
>
> Converts to
>
> this_cpu_write(y, x);
>
>
> 6. Increment/Decrement etc of a per cpu variable
>
> DEFINE_PER_CPU(int, y);
> __get_cpu_var(y)++
>
> Converts to
>
> this_cpu_inc(y)
>
>
>
> Signed-off-by: Christoph Lameter <cl@...ux.com>
>
> Index: linux/drivers/leds/trigger/ledtrig-cpu.c
> ===================================================================
> --- linux.orig/drivers/leds/trigger/ledtrig-cpu.c 2013-08-27 14:46:42.043176071 -0500
> +++ linux/drivers/leds/trigger/ledtrig-cpu.c 2013-08-27 14:46:42.035176153 -0500
> @@ -46,7 +46,7 @@ static DEFINE_PER_CPU(struct led_trigger
> */
> void ledtrig_cpu(enum cpu_led_event ledevt)
> {
> - struct led_trigger_cpu *trig = &__get_cpu_var(cpu_trig);
> + struct led_trigger_cpu *trig = this_cpu_ptr(&cpu_trig);
>
Sure, please go ahead with my ack.
Acked-by: Bryan Wu <cooloney@...il.com>
> /* Locate the correct CPU LED */
> switch (ledevt) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists