[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Better CLONE_SETTLS support for Hammer
Hash: SHA1

Andi Kleen wrote:

> You want the change, not me ;)

But I cannot test it since the kernel doesn't work.

> It should already work on the current kernel, modulo clone.
> (but arch_prctl, set_thread_area in 2.5, ldt in 2.4 etc.)

I cannot confirm this. I wasted a lot of time on getting it to work.
Without avail.

> It's needed for 32bit emulation at least. The code is 100% shared
> between the emulation and the native 64bit model.
> In theory it could be removed from the system call table for 64bit
> but there didn't seem a good reason to do so - after all 64bit programs
> can put their thread local data into the first 4GB and
> fast context switches.
>>the use of prctl to get and set the base address. Then internally in
>>the prctl call map it to either the use of a 32 base address segment or
>>use the MSR.
> The problem is that the 64bit base has different semantics.
> When you use a segment register you have to do:
> call kernel to set gdt/ldt
> movl index,%%fs
> But when the kernel did set the 64bit base in the kernel call the
> following movl to the selector would destroy it again
> Loading the index inside the system call would also be problematic:
> First it would be different from what i386 does, causing porting headaches.
> Also you could not easily do it from a different thread unlike the
> LDT load.
>>This way whoever needs a segment base address can preferably allocate it
>>in the low 4GB, but if it fails the kernel support still work. And with
>>the same interface. Currently this is not the case and this is not
> That should already work and it is in fact how I imagined this to be:
> do MAP_32BIT - if yes use set_thread_area or an LDT entry;
> if not use arch_prctl
> The NPTL signal race problem for the clones in case you have a 64bit
> base is a bit ugly though I agree.
> I don't like your patch currently because it'll guarantee slow
> context switch times for 64bit.
> Automatic switching based on the set bits in the base may be possible
> (in fact I had something like this in set_thread_area for some time, but
> removed it because of the ugly semantics because set_thread_area doesn't
> already load the selector). If the selector load is forced
> in clone however it would not be as weird, just only somewhat
> ugly. You'll have to guarantee in user space then that you don't
> reload it.
> Real solution would be Windowish - Create clone7() with both
> selectors and bases
> [I suspect 2.8 and 3.0 will get that anyways as experience
> on other operating systems who started on the same path
> shows. e.g. AmigaOS grew more CreateTask
> variants with more arguments with each release until they eventually
> settled on passing tag lists.]
> -Andi

- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at `---------------------------
Version: GnuPG v1.2.1 (GNU/Linux)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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