From: Rusty Russell <rusty@rustcorp.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Paul Mackerras <paulus@samba.org>,
Andi Kleen <andi@firstfloor.org>,
"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>,
linux-kernel@vger.kernel.org
Subject: Re: _proxy_pda still makes linking modules fail
Date: Wed, 14 Mar 2007 12:12:49 +1100 [thread overview]
Message-ID: <1173834769.5443.3.camel@localhost.localdomain> (raw)
In-Reply-To: <45F6C3E9.5020207@goop.org>
On Tue, 2007-03-13 at 08:31 -0700, Jeremy Fitzhardinge wrote:
> Paul Mackerras wrote:
> > There is a fundamental problem with using __thread, which is that gcc
> > assumes that the addresses of __thread variables are constant within
> > one thread, and that therefore it can cache the result of address
> > calculations. However, with preempt, threads in the kernel can't rely
> > on staying on one cpu, and therefore the addresses of per-cpu
> > variables can change. There appears to be no way to tell gcc to drop
> > all cached __thread variable address calculations at a given point
> > (e.g. when enabling or disabling preemption). That is basically why I
> > gave up on using __thread for per-cpu variables on powerpc.
[ Thanks for the enlightenment, Paul ]
> Doesn't that fall under the general class of "you have to be pinned to a
> particular cpu in order to meaningfully use per-cpu variables"?
No, it makes assumptions about the *address* of a per-cpu variable not
changing, even across barriers.
> In principle gcc could CSE the value of smp_processor_id() across a cpu
> change in the same way.
No, this is why preempt_enable and the like are memory barriers.
Rusty.
next prev parent reply other threads:[~2007-03-14 1:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 0:57 _proxy_pda still makes linking modules fail Marcin 'Qrczak' Kowalczyk
2007-03-10 15:03 ` Adrian Bunk
2007-03-11 14:06 ` Marcin 'Qrczak' Kowalczyk
2007-03-12 1:19 ` Andi Kleen
2007-03-12 0:25 ` Jeremy Fitzhardinge
2007-03-12 9:48 ` Andi Kleen
2007-03-12 14:45 ` Jeremy Fitzhardinge
2007-03-12 15:45 ` Andi Kleen
2007-03-12 21:58 ` Rusty Russell
2007-03-13 6:23 ` Rusty Russell
2007-03-13 9:04 ` Paul Mackerras
2007-03-13 15:31 ` Jeremy Fitzhardinge
2007-03-13 23:50 ` Paul Mackerras
2007-03-14 1:12 ` Rusty Russell [this message]
2007-03-13 15:57 ` Andi Kleen
2007-03-14 2:17 ` Rusty Russell
2007-03-12 18:47 ` Marcin 'Qrczak' Kowalczyk
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=1173834769.5443.3.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=andi@firstfloor.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=qrczak@knm.org.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.