Messages in this thread | | | Date | Sat, 01 Aug 2009 20:52:06 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [GIT PULL] Additional x86 fixes for 2.6.31-rc5 |
| |
On 08/01/2009 06:20 PM, Paul Mackerras wrote: > When I tried using __thread for per-cpu variables on ppc64, I found > that gcc would sometimes precompute and cache the address of a per-cpu > variable even though it could always access the variable using an > offset from r13. The cached address was wrong if the task got moved > to a different cpu, of course, but there was no way to tell gcc that. > Compiler barriers don't help because they say that the contents of > variables might have changed, but not their addresses. > > So on x86 the concern would be that gcc might do lea %gs:foo,%rbx and > then use (%rbx) to refer to foo later on. It would be possible to use > __thread for per-task variables rather than having to put all per-task > things in the task_struct, but __thread doesn't work for per-cpu > variables in my experience.
You can't actually do "lea %gs:foo,%rbx" (lea doesn't include the segment offset, unfortunately; I asked AMD to change that on 64 bits but, not too surprisingly, they weren't able to make that change.) Getting the address is expensive, but it's obviously possible -- which may have similar bad results. It would be worth experimenting with a little bit, though.
-hpa
-- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
| |