2.4, 2.6, i686/athlon and LDT's

2.4, 2.6, i686/athlon and LDT's

[Tymm Twillman]

Hi all,

I've some questions about LDT usage WRT threads.  I'm working currently 
with 2.4 kernels (although will be moving to 2.6 relatively soon) and 
have had a lot of difficulty finding decent resources to adequately 
explain proper LDT usage (from really why they're used to the 
complexities of actually using them). 

Context here is process freezing/restoring and how to properly 
save/restore LDT entries for a given process -- with 2.4, glibc will 
call modify_ldt() whenever the pthreads library is linked in (regardless 
of whether threads are actually used, and regardless of whether there 
are multiple threads currently running) on i686/athlon platforms to set 
up a thread-specific storage area.  (I'm not looking to save/restore all 
information for individual threads; that could get icky with multiple 
threads running). 

It appears that use of the LDT is to speed up context switching between 
threads, although I haven't even found especially good references WRT 
that.  I have looked through the info in the IA Developers publications 
and have whacked my head against Google quite a bit.  However, every bit 
of clarity I've found there has been offset by new confuzled bits.

I also have found it's possible to compile glibc not to use LDT's on 
these platforms; does anyone have comparison information w/threads using 
LDT's and without (performance, protection, etc)?

Also, 2.6 appears to have moved to a tss storage area attributed with 
each thread in the thread_struct... I'll be digging into that soon 
enough, but if anyone has quick information on comparing this to the 2.4 
tss mechanism I'd appreciate it; mainly regarding whether LDT's are 
involved and if there are any gotchas there, or if it's much simpler and 
doesn't need anything special to use.  Also if it doesn't use LDT's, 
what's the performance impact in moving away from them?

I'm not looking for information on saving/restoring processes outside 
the LDT-specific bits -- I'm set on pretty much everything else.

Thanks for your time,

-Tymm

Re: 2.4, 2.6, i686/athlon and LDT's

[Arjan van de Ven]

On Mon, 2004-12-27 at 11:46 -0800, Tymm Twillman wrote:
> Hi all,

> 
> It appears that use of the LDT is to speed up context switching between 
> threads, although I haven't even found especially good references WRT 
> that.  I have looked through the info in the IA Developers publications 
> and have whacked my head against Google quite a bit.  However, every bit 
> of clarity I've found there has been offset by new confuzled bits.

LDT's are *slow*. That's why glibc will try to avoid using them
nowadays, and with 2.6 it won't; as for 2.4.. it depends if you use a
vendor 2.4 it might be able to avoid using LDT's as well.

Re: 2.4, 2.6, i686/athlon and LDT's

[Brian Gerst]

Arjan van de Ven wrote:
> On Mon, 2004-12-27 at 11:46 -0800, Tymm Twillman wrote:
> 
>>Hi all,
> 
> 
>>It appears that use of the LDT is to speed up context switching between 
>>threads, although I haven't even found especially good references WRT 
>>that.  I have looked through the info in the IA Developers publications 
>>and have whacked my head against Google quite a bit.  However, every bit 
>>of clarity I've found there has been offset by new confuzled bits.
> 
> 
> LDT's are *slow*. That's why glibc will try to avoid using them
> nowadays, and with 2.6 it won't; as for 2.4.. it depends if you use a
> vendor 2.4 it might be able to avoid using LDT's as well.

Using the LDT isn't inherently slower, since the cpu caches the segment 
descriptor regardless of if it came from the GDT or LDT.  Using an LDT 
however consumes kernel memory, which can slow down the system from 
memory pressure if you have many processes/threads using them.

--
				Brian Gerst

Re: 2.4, 2.6, i686/athlon and LDT's

[Arjan van de Ven]

On Mon, 2004-12-27 at 15:55 -0500, Brian Gerst wrote:
> Arjan van de Ven wrote:
> > On Mon, 2004-12-27 at 11:46 -0800, Tymm Twillman wrote:
> > 
> >>Hi all,
> > 
> > 
> >>It appears that use of the LDT is to speed up context switching between 
> >>threads, although I haven't even found especially good references WRT 
> >>that.  I have looked through the info in the IA Developers publications 
> >>and have whacked my head against Google quite a bit.  However, every bit 
> >>of clarity I've found there has been offset by new confuzled bits.
> > 
> > 
> > LDT's are *slow*. That's why glibc will try to avoid using them
> > nowadays, and with 2.6 it won't; as for 2.4.. it depends if you use a
> > vendor 2.4 it might be able to avoid using LDT's as well.
> 
> Using the LDT isn't inherently slower, since the cpu caches the segment 
> descriptor regardless of if it came from the GDT or LDT. 

it does however increase context switch costs significantly since the
LDT needs to be reloaded and reverified...

Re: 2.4, 2.6, i686/athlon and LDT's

[Ulrich Drepper]

On Mon, 27 Dec 2004 15:55:53 -0500, Brian Gerst <bgerst@didntduck.org> wrote:
> Using the LDT isn't inherently slower, since the cpu caches the segment
> descriptor regardless of if it came from the GDT or LDT.

Not using LDT's on 2.4 kernel other than RHEL3's means to have a
different ABI.  This is the /lib/libpthread.so.0 RH is shipping which
simply cannot be used in some/many situations since there is no
"thread register".  This means the programmer is not able to select
size and/or location of the stacks.  Interfaces like
pthread_attr_setstack() simply won't work at all.

So, do't confuse people with "does anyone have comparison information
w/threads using
LDT's and without (performance, protection, etc)?".  That's comparing
apples and oranges.