public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tymm Twillman <ttwillman@penguincomputing.com>
To: linux-kernel@vger.kernel.org
Subject: 2.4, 2.6, i686/athlon and LDT's
Date: Mon, 27 Dec 2004 11:46:19 -0800	[thread overview]
Message-ID: <41D0668B.206@penguincomputing.com> (raw)

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

             reply	other threads:[~2004-12-27 19:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-27 19:46 Tymm Twillman [this message]
2004-12-27 20:22 ` 2.4, 2.6, i686/athlon and LDT's Arjan van de Ven
2004-12-27 20:55   ` Brian Gerst
2004-12-27 21:29     ` Arjan van de Ven
2004-12-27 23:44     ` Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41D0668B.206@penguincomputing.com \
    --to=ttwillman@penguincomputing.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox