All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	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: Tue, 13 Mar 2007 08:31:53 -0700	[thread overview]
Message-ID: <45F6C3E9.5020207@goop.org> (raw)
In-Reply-To: <17910.26926.138067.731855@cargo.ozlabs.ibm.com>

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.
>   

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"?

Or do you mean that if you have:

	preempt_disable();
	use_my_percpu++;
	preempt_enable();
	// switch cpus
	preempt_disable();
	use_my_percpu++;
	preempt_enable();

then it will still use the old pointer to use_my_percpu?

In principle gcc could CSE the value of smp_processor_id() across a cpu
change in the same way.

    J

  reply	other threads:[~2007-03-13 15:31 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 [this message]
2007-03-13 23:50               ` Paul Mackerras
2007-03-14  1:12               ` Rusty Russell
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=45F6C3E9.5020207@goop.org \
    --to=jeremy@goop.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=qrczak@knm.org.pl \
    --cc=rusty@rustcorp.com.au \
    /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.