[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49C300D8.5080204@kernel.org>
Date: Fri, 20 Mar 2009 11:35:04 +0900
From: Tejun Heo <tj@...nel.org>
To: Martin Schwidefsky <schwidefsky@...ibm.com>
CC: mingo@...e.hu, rusty@...tcorp.com.au, tglx@...utronix.de,
x86@...nel.org, linux-kernel@...r.kernel.org, hpa@...or.com,
Paul Mundt <lethal@...ux-sh.org>, rmk@....linux.org.uk,
starvik@...s.com, ralf@...ux-mips.org, davem@...emloft.net,
cooloney@...nel.org, kyle@...artin.ca, matthew@....cx,
grundler@...isc-linux.org, takata@...ux-m32r.org,
benh@...nel.crashing.org, rth@...ddle.net,
ink@...assic.park.msu.ru, heiko.carstens@...ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default
percpu allocator
Hello, Martin.
Sorry about the delay.
Martin Schwidefsky wrote:
> We do have a problem with #2, the dynamic percpu patches currently
> breaks s390. But the nice thing is that we can now get rid of the GOTENT
> relocation for the percpu symbols. If the code is changed to use
> RELOC_HIDE for the SHIFT_PERCPU_PTR define, everything works just fine.
> Patch attached. Nice works guys.
>
> Subject: [PATCH] s390: percpu access.
>
> From: Martin Schwidefsky <schwidefsky@...ibm.com>
>
> With the dynamic percpu allocator there is no need anymore to play
> tricks with the GOTENT relocation for the access to the percpu
> symbols. A simple RELOC_HIDE gets the job done.
Hmm... I don't quite get it. The GOTENT was to work around large
offsets for modules, right? Can you please explain what changed by
the dynamic percpu allocator?
> +#define SHIFT_PERCPU_PTR(var, offset) RELOC_HIDE(&per_cpu_var(var), (offset))
Hmm... @var already has per_cpu__ prefix when the above macro is
invoked, so doing per_cpu_var() on it again wouldn't work. If simple
RELOC_HIDE works, you should be able to simply drop the above
definition. The generic percpu.h will define it.
Thanks.
--
tejun
--
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