lkml.org 
[lkml]   [2006]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/6] Initialize the per-CPU data area.
Andi Kleen wrote:
>> I'll respin it against your patches later today.
>>
>
> Thanks. It's not that urgent because the merge will need a few days
> at least.
>

I guess I should just use plain 2.6.19 as a base.

> Also I must admit I haven't figured out yet if yours or Rusty's patchkit
> is better. So far I was leaning towards yours, but that might be because
> I haven't looked closely at Rusty's version.

The basic machinery is similar, though he's gone and made things like
the per-cpu GDTs actual percpu variables, with a bit of gymnastics to
use them from assembler. I haven't looked at the last iteration which
does all the setup in the head.S assembler.

On the plus side, he makes some use of %gs to reference percpu data, and
it's a nice simple patch to do so. One slightly odd aspect of it is
that %gs:0 is actually at a large offset below the percpu memory, in
order to compensate for the offset of the percpu data section in the
kernel address space.

And in my heart of hearts I'd prefer to use the compiler TLS support to
do this; it gets better generated code (at least in the non-Xen case),
with the downside of needing some more support in the module loader. It
also gets rid of all the special access macros/assembler for percpu
variables. (And ideally we can convince the gcc folks to allow
generation of positive offset TLS relocations, and solve the Xen problem
that way.)

J
-
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: 2006-09-25 23:35    [W:0.032 / U:21.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site