lkml.org 
[lkml]   [2002]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.5.1-pre5: per-cpu areas
On Thu, Mar 14, 2002 at 03:37:38PM +1100, Rusty Russell wrote:
> > I am also a bit concerned however about aliasing that the compiler
> > might not detect. For example, with this code:
> >
> > this_cpu(foo) = 13;
> > per_cpu(foo, 0) = 15;
> > printf("foo=%d\n", this_cpu(foo);
> >
> > might print the wrong value if gcc thinks that the first and second
> > assignment never alias each other. Does HIDE_RELOC() take care of
> > this also?
>
> I'd be pretty sure the compiler can't assume that. Richard would
> know...

I can't think of a way your current code is invalid. It's all
hidden behind an asm. The compiler could guess the two addresses
are the same iff smp_processor_id() is the constant 0, aka UP.

> > On a side-note, would you mind moving __per_cpu_data from smp.h into
> > compiler.h? I'd like to use it in processor.h and from that file, I
> > can't include smp.h due to a recursive dependency.

This definitely needs to be per-architecture. On Alpha, I think I
can use the Thread Local Storage model to be added to binutils 2.13
(and potentially compiler support to gcc 3.[23]). IA-64 may be able
to do the same. It's certain that x86 can't, since the userland
model requires %gs:0 point to the thread base, and the kernel folk
would never cotton to the segment swapping that would be needed.



r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:1.649 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site