Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)

[Andrea Arcangeli]

On Thu, Mar 04, 2004 at 03:37:55AM -0500, Jakub Jelinek wrote:
> On Thu, Mar 04, 2004 at 08:00:56AM +0000, Jamie Lokier wrote:
> > Andrea Arcangeli wrote:
> > > I will try again with NTPL since it seems they didn't fix it (at
> > > least last time I checked the code the LDT waste as still there).
> > 
> > Does NPTL use the LDT at all?  sys_set_thread_area was created
> > specifically so that the LDT isn't needed.
> 
> It doesn't and neither does LinuxThreads when run on a recent kernel
> (which has set_thread_area).

I really thought set_thread_area would depend on a LDT being allocated
first, I was wrong sorry, the parameter passed is in the same format of
modify_ldt (that's what fooled me) but it seems used only to write
directly into the gdt, it's not an entry in the ldt but it's an entry
into the gdt, and the gdt is overwritten at every thread switch (not at
every mm switch). So as far as glibc doesn't allocate the LDT and only
uses this logic the problem I mentioned (using 2.4 kernels) is just
solved and I really appreciate this. The thing that scared me most (and
that hurted me most in deferring the allocation to pthread_create with
2.4 kernels) is that at least in linuxthreads the ldt allocation spreads
out of the linuxthread package (it spreads into the dynamic linker IIRC,
but I looked at last time a few months ago), I hope with nptl this is
fixed too.  clearly the ldt had to be nuked somehow to get past some
thousand threads anyways, but avoiding the ldt allocation is an even more
important feature in real life with real apps not using threads but just
linking with pthreads by mistake like /bin/ls.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/