From: Tejun Heo <tj@kernel.org>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: mingo@elte.hu, rusty@rustcorp.com.au, tglx@linutronix.de,
x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com,
Paul Mundt <lethal@linux-sh.org>,
rmk@arm.linux.org.uk, starvik@axis.com, ralf@linux-mips.org,
davem@davemloft.net, cooloney@kernel.org, kyle@mcmartin.ca,
matthew@wil.cx, grundler@parisc-linux.org, takata@linux-m32r.org,
benh@kernel.crashing.org, rth@twiddle.net,
ink@jurassic.park.msu.ru, heiko.carstens@de.ibm.com
Subject: Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator
Date: Wed, 25 Mar 2009 20:51:31 +0900 [thread overview]
Message-ID: <49CA1AC3.9080908@kernel.org> (raw)
In-Reply-To: <20090325122738.42d105b7@skybase>
Hello, Martin.
Martin Schwidefsky wrote:
>>>> 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?
>
> Unfortunately it didn't change. The problem is still there, only with
> my particular configuration (and the correct patch) the system did
> work because the problematic modules were not in use. But in general it
> won't work.
>
> The reason for the GOTENT indirection are static per-cpu variables that
> are defined inside a module. The compiler considers these to be local.
> For locally defined per_cpu__#var symbols the compiler uses an
> instruction that is limited to the scope of a single object, which is
> +-4 GB. The trick with GOTENT introduced an indirection which hid the
> problem.
>
> Without the GOTENT indirection the access to a static per cpu variable
> will look like this:
>
> 0000000000000000 <test_fn>:
> 0: e3 30 03 30 00 04 lg %r3,816
> 6: c0 10 00 00 00 00 larl %r1,6 <test_fn+0x6>
> 8: R_390_PC32DBL .data.percpu+0x2
> c: e3 23 10 00 00 04 lg %r2,0(%r3,%r1)
>
> The R_390_PC32DBL relocation in the module relocation will fail if the
> per-cpu area is farther than 4GB away from the vmalloc area.
Okay, up to this point, I understand, so nothing really changed for
symbols (core or modules) by the dynamic percpu allocator and they
still need GOTENT, right?
> With your patches and a RELOC_HIDE version that uses the GOTENT
> indirection the kernel won't compile because the "X" constraint for
> the GOTENT access needs a symbol and there are quite a few users that
> pass a pointer. I do not see a simple solution for that problem yet.
Ah... okay. Now I get it. It wasn't expecting variables there. How
about doing the following?
#define SHIFT_PERCPU_PTR(ptr, offset) (({ \
if (__builtin_constant_p(ptr)) \
do GOTENT trick; \
else \
RELOC_HIDE(); \
}))
Thanks.
--
tejun
next prev parent reply other threads:[~2009-03-25 11:55 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-10 7:53 [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator Tejun Heo
2009-03-10 7:53 ` [PATCH 1/5] linker script: define __per_cpu_load on all SMP capable archs Tejun Heo
2009-03-10 7:53 ` [PATCH 2/5] percpu: make x86 addr <-> pcpu ptr conversion macros generic Tejun Heo
2009-03-10 7:53 ` [PATCH 3/5] percpu: more flexibility for @dyn_size of pcpu_setup_first_chunk() Tejun Heo
2009-03-10 7:53 ` [PATCH 4/5] percpu: generalize embedding first chunk setup helper Tejun Heo
2009-03-10 7:53 ` [PATCH 5/5] percpu: use dynamic percpu allocator as the default percpu allocator Tejun Heo
2009-03-10 7:57 ` test module to verify " Tejun Heo
2009-03-10 10:59 ` [GIT RFC] percpu: use dynamic percpu allocator as the default " David Miller
2009-03-11 6:03 ` Tejun Heo
2009-03-11 5:56 ` [GIT PULL] pull request for safe part Tejun Heo
2009-03-16 18:01 ` [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator Martin Schwidefsky
2009-03-20 2:35 ` Tejun Heo
2009-03-24 15:22 ` Tejun Heo
2009-03-25 11:27 ` Martin Schwidefsky
2009-03-25 11:51 ` Tejun Heo [this message]
2009-03-25 12:22 ` Ingo Molnar
2009-03-25 12:27 ` Tejun Heo
2009-03-25 12:39 ` Ingo Molnar
2009-03-25 13:13 ` Martin Schwidefsky
2009-03-25 13:21 ` Tejun Heo
2009-03-25 13:25 ` Martin Schwidefsky
2009-03-25 13:34 ` Tejun Heo
2009-03-31 16:54 ` Martin Schwidefsky
2009-03-31 17:20 ` Christoph Lameter
2009-03-31 20:18 ` Martin Schwidefsky
2009-03-31 21:10 ` Christoph Lameter
2009-04-01 8:01 ` Martin Schwidefsky
2009-03-31 19:17 ` Ivan Kokshaysky
2009-03-31 20:19 ` Martin Schwidefsky
2009-03-31 20:29 ` Ivan Kokshaysky
2009-04-01 0:07 ` Tejun Heo
2009-04-01 8:10 ` Martin Schwidefsky
2009-04-01 8:17 ` Tejun Heo
2009-04-01 8:32 ` Martin Schwidefsky
2009-04-01 8:37 ` David Miller
2009-04-01 8:47 ` Martin Schwidefsky
2009-04-01 8:50 ` Tejun Heo
2009-04-01 9:08 ` Martin Schwidefsky
2009-04-02 1:54 ` Tejun Heo
2009-04-01 8:53 ` David Miller
2009-04-01 8:53 ` Tejun Heo
2009-04-01 11:07 ` Martin Schwidefsky
2009-04-02 1:57 ` Tejun Heo
2009-04-02 7:24 ` Ivan Kokshaysky
2009-04-02 11:13 ` Martin Schwidefsky
2009-04-03 0:31 ` Tejun Heo
2009-04-07 16:09 ` Ivan Kokshaysky
2009-04-08 20:18 ` Tejun Heo
2009-04-09 9:47 ` Ivan Kokshaysky
2009-04-09 11:53 ` Tejun Heo
2009-04-11 1:38 ` Rusty Russell
2009-04-11 1:52 ` Tejun Heo
2009-04-02 0:20 ` Rusty Russell
2009-03-25 14:00 ` Martin Schwidefsky
2009-03-25 14:14 ` Tejun Heo
2009-03-30 10:07 ` [PATCH UPDATED] " Tejun Heo
2009-03-30 10:42 ` Martin Schwidefsky
2009-04-01 0:08 ` Tejun Heo
2009-03-30 11:49 ` Ingo Molnar
2009-03-30 14:50 ` Christoph Lameter
2009-03-31 16:12 ` Christoph Lameter
2009-04-01 0:15 ` Tejun Heo
2009-04-01 13:49 ` Christoph Lameter
2009-04-01 15:49 ` Ingo Molnar
2009-04-01 18:06 ` Christoph Lameter
2009-04-01 19:01 ` Ingo Molnar
2009-04-01 19:39 ` Linus Torvalds
2009-04-01 20:12 ` Matthew Wilcox
2009-04-02 2:13 ` Ingo Molnar
2009-04-01 22:32 ` Ingo Molnar
2009-04-01 22:57 ` Matthew Wilcox
2009-04-02 2:10 ` Ingo Molnar
2009-04-02 2:21 ` Christoph Lameter
2009-04-02 3:25 ` Ingo Molnar
2009-04-02 3:28 ` Christoph Lameter
2009-04-02 2:30 ` Tejun Heo
2009-04-02 2:18 ` Christoph Lameter
2009-04-02 3:42 ` Ingo Molnar
2009-04-02 13:53 ` Christoph Lameter
2009-04-08 16:26 ` Ingo Molnar
2009-04-13 18:18 ` Christoph Lameter
2009-04-14 14:04 ` Ingo Molnar
2009-04-14 16:48 ` Christoph Lameter
2009-04-14 17:12 ` Ingo Molnar
2009-04-02 2:15 ` Christoph Lameter
2009-04-02 4:19 ` [PATCH 1/2 x86#core/percpu] percpu: don't put the first chunk in reverse-map rbtree Tejun Heo
2009-04-02 4:21 ` [PATCH 2/2 x86#core/percpu] percpu: remove rbtree and use page->index instead Tejun Heo
2009-04-08 17:03 ` [tip:core/percpu] " Christoph Lameter
2009-04-08 17:03 ` [tip:core/percpu] percpu: don't put the first chunk in reverse-map rbtree Tejun Heo
2009-03-31 16:14 ` [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator Christoph Lameter
2009-04-01 0:18 ` Tejun Heo
2009-03-31 1:34 ` Rusty Russell
2009-03-31 22:57 ` David Miller
2009-03-31 23:49 ` Benjamin Herrenschmidt
2009-04-01 0:19 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49CA1AC3.9080908@kernel.org \
--to=tj@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=cooloney@kernel.org \
--cc=davem@davemloft.net \
--cc=grundler@parisc-linux.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=ink@jurassic.park.msu.ru \
--cc=kyle@mcmartin.ca \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mingo@elte.hu \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=rth@twiddle.net \
--cc=rusty@rustcorp.com.au \
--cc=schwidefsky@de.ibm.com \
--cc=starvik@axis.com \
--cc=takata@linux-m32r.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).