Messages in this thread | | | Date | Thu, 29 Jan 2009 13:33:13 -0500 (EST) | From | Christoph Lameter <> | Subject | Re: [PATCH] percpu: add optimized generic percpu accessors |
| |
On Wed, 28 Jan 2009, Mathieu Desnoyers wrote:
> > The term cpu is meaning multiple things at this point. So yes it may be > > better to go with glibc naming of thread local space. > > > > However using "local" for "per-cpu" could be confusing with the glibc > naming of thread local space, because "per-thread" and "per-cpu" > variables are different from a synchronization POV and we can end up > needing both (e.g. a thread local variable can never be accessed by > another thread, but a cpu local variable could be accessed by a > different CPU due to scheduling).
gcc/glibc support a __thread attribute to variables. As far as I can tell this automatically makes gcc perform the relocation to the current context using a segment register.
But its a weird ABI http://people.redhat.com/drepper/tls.pdf. After reading that I agree that we should stay with the cpu ops and forget about the local and thread stuff in gcc/glibc.
| |