Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Tue, 31 Mar 2009 13:20:42 -0400 (EDT)
Christoph Lameter <cl@linux.com> wrote:

> On Tue, 31 Mar 2009, Martin Schwidefsky wrote:
> 
> > I got the dynamic cpu allocator to work with the patch below. Anybody
> > with an objection against the SHIFT_PERCPU_VAR macro ?
> 
> Please include the patch inline next time.

What do you mean by "inline"? That the patch should not be the last
thing in the mail?

> Why is there a difference between percpu alloc and "static" percpu
> variables? The "static" percpu variables can be dynamically allocated when
> a module is loaded.

We need to hide the static per cpu symbol from the compiler, otherwise
the compiler will try to load the address of the symbol with an
instruction that is limited in the addressing range of a single elf
object. We do that will the inline assembly in SHIFT_PERCPU_PTR

#define SHIFT_PERCPU_PTR(ptr,offset) (({                \
        extern int simple_identifier_##var(void);       \
        unsigned long *__ptr;                           \
        asm ( "larl %0, %1@GOTENT"                      \
            : "=a" (__ptr) : "X" (ptr) );               \
        (typeof(ptr))((*__ptr) + (offset));     }))

The "X" constraint only works if ptr is the name of a symbol. The
per_cpu_ptr macro will use SHIFT_PERCPU_PTR on an pointer which does
not compile. For pointers we do not need to trick the compiler, we can
just use the standard RELOC_HIDE.

> Isnt this mmore an issue that can be addressed by changing the way the initial per cpu
> segment is allocated? If its also dynamically allocated then there should
> be no problem?
 
I don't see how changes to the initial per cpu segment should help with
access to per cpu symbols.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.