[lkml]   [2002]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel: ldt allocation failed
Followup to:  <>
By author:
In newsgroup:
> On Wed, Feb 06, 2002 at 10:12:31AM -0500, Jakub Jelinek wrote:
> > Most sane architectures reserve a thread pointer register (%g6 resp. %g7 on
> > sparc, tp on ia64, ppc will use %r2, alpha uses a fast pall call as thread
> > "register", s390 uses user access register 0 (and s390x uar 0 and 1), etc.).
> > On register starved ia32 there aren't too many spare registers, so %gs is
> > used instead.
> So the x86 designers have provided all sorts of shadow registers and extensive
> high speed caches and the glibc developers deliberately choose to defeat all that
> expensive optimization?

Uhm... none of that "expensive optimization" will help you here,
because you need *architectural storage*. Archtectural storage is
always a fundamentally limited resource, regardless of how many shadow
registers you add.

However, an x86 has a whole additional register file which is rarely
used these days -- the segment register file. The segment register
file is mainly useful when the main usage is address offsetting, since
it provides an extra input into the address adder. For this
particular purpose, using it is very much the sane thing to do.

As far as %gs switching is concerned, using %gs doesn't automatically
mean using the LDT. There are two ways you can avoid setting up LDTs
in single-threaded apps, and still allow an ABI compatible with the
threaded apps:

a) For single-threaded apps, define %gs == %ds. Less than ideal for
several reasons, but no kernel mods needed.

b) Have the kernel provide another GDT value which can be used by the
single-threaded apps.

<> at work, <> in private!
"Unix gives you enough rope to shoot yourself in the foot." <>
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:24    [W:0.111 / U:5.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site