From: Jakub Jelinek <jakub@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel: ldt allocation failed
Date: Wed, 6 Feb 2002 17:20:25 -0500 [thread overview]
Message-ID: <20020206172025.H21624@devserv.devel.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0112070057480.20196-100000@tombigbee.pixar.com.suse.lists.linux.kernel> <200202061402.g16E2Nt32223@Port.imtp.ilyichevsk.odessa.ua> <20020206101231.X21624@devserv.devel.redhat.com> <20020206132144.A29162@hq.fsmlabs.com> <a3s5gs$94v$1@cesium.transmeta.com> <20020206163118.E21624@devserv.devel.redhat.com> <3C61A8C0.7000406@zytor.com>
In-Reply-To: <3C61A8C0.7000406@zytor.com>; from hpa@zytor.com on Wed, Feb 06, 2002 at 02:05:52PM -0800
On Wed, Feb 06, 2002 at 02:05:52PM -0800, H. Peter Anvin wrote:
> >>b) Have the kernel provide another GDT value which can be used by the
> >> single-threaded apps.
> >>
> >
> > Like above, a fixed address for mmap would have to be chosen, but the
> > advantage would be that the TLS ABI would need no changing.
> > Simply kernel would add 0x33 to GDT as 4KB -> 0xc0000000 user data segment
> > and apps could put that value into %gs if not using threads.
> >
> > But I think there is c) and d).
> > c) is just minor modification of current ldt handling in kernel, which would
> > mean a single entry LDT (residing in task_struct) could be used instead
> > of vmalloced one - this has the disadvantage of lldt on almost every
> > context switch
> > d) default to a single-entry per-cpu LDT, which only non-linux personality
> > apps and apps needing more than 1 LDT entry (threaded apps, wine/dosemu/...)
> > would not use. Non-linux apps would use current default_ldt and those
> > needing more than one LDT would use the current vmalloced mm private area.
> > If a task would be using this per-cpu LDT (common case), context switch
> > would do lldt only if previous task was not using the per-cpu LDT
> > (unlikely) and just store task_struct->thread.ldt_word_0 and ldt_word_1
> > into the per-cpu LDT (dunno how expensive is that, but IMHO it should be
> > cheaper than full load_LDT).
> >
>
>
> Actually d) is probably better done by allowing CPUs to put *one* entry in
> the GDT instead of requesting an LDT. Since the LDT takes up a GDT entry
> anyway, this should be simple enough.
On UP sure, on SMP you'd need to allocate as many GDT entries as there are
CPUs and special case this in __switch_to too (something like
loadsegment(fs, next->fs);
if ((next->gs & 7) == 3 && next->gs >= 0x30 && next->gs < 0x30 + NR_CPUS * 8)
next->gs = smp_processor_id() * 8 + 0x33;
loadsegment(gs, next->gs);
) which is kind of ugly (and userland must not save/restore %gs itself then).
Unlike d) with LDT, where unmodified glibc could work with older kernels
too, thus would mean strict kernel minimum version requirement (with LDT d)
it would be just an optimization).
Jakub
next prev parent reply other threads:[~2002-02-06 22:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.21.0112070057480.20196-100000@tombigbee.pixar.com.suse.lists.linux.kernel>
[not found] ` <5.1.0.14.2.20011207092244.049f6720@pop.cus.cam.ac.uk.suse.lists.linux.kernel>
[not found] ` <200202061258.g16CwGt31197@Port.imtp.ilyichevsk.odessa.ua.suse.lists.linux.kernel>
2002-02-06 13:19 ` kernel: ldt allocation failed Andi Kleen
2002-02-06 14:06 ` Dave Jones
2002-02-06 14:13 ` Alan Cox
2002-02-06 14:09 ` Andi Kleen
2002-02-06 14:39 ` Alan Cox
2002-02-06 16:37 ` bert hubert
2002-02-06 15:51 ` Bill Davidsen
2002-02-06 16:08 ` Alan Cox
2002-02-06 16:29 ` John Levon
2002-02-06 18:01 ` Alan Cox
2002-02-06 18:02 ` Denis Vlasenko
2002-02-06 15:12 ` Jakub Jelinek
2002-02-06 18:11 ` Maciej W. Rozycki
2002-02-06 20:19 ` H. Peter Anvin
2002-02-06 21:15 ` Jakub Jelinek
2002-02-06 21:17 ` H. Peter Anvin
2002-02-06 20:21 ` yodaiken
2002-02-06 21:00 ` H. Peter Anvin
2002-02-06 21:31 ` Jakub Jelinek
2002-02-06 22:05 ` H. Peter Anvin
2002-02-06 22:20 ` Jakub Jelinek [this message]
2002-02-06 23:35 ` H. Peter Anvin
2002-02-07 0:21 ` Alan Cox
2002-02-07 0:12 ` Jakub Jelinek
2002-02-07 0:15 ` H. Peter Anvin
2002-02-07 0:13 ` H. Peter Anvin
2002-02-06 15:37 ` Alan Cox
[not found] <fa.kit1f7v.j024op@ifi.uio.no>
2001-12-07 7:24 ` Dan Maas
2001-12-07 9:00 ` Kiril Vidimce
2001-12-07 9:15 ` Alan Cox
2001-12-07 9:13 ` Kiril Vidimce
2001-12-07 9:28 ` Alan Cox
2001-12-07 9:26 ` James Davies
2001-12-07 9:43 ` Alan Cox
2001-12-07 13:10 ` James Davies
2001-12-07 13:41 ` Dave Jones
2001-12-07 13:59 ` James Davies
2001-12-07 13:53 ` Alan Cox
2001-12-07 9:45 ` Anton Altaparmakov
2001-12-07 10:38 ` Alan Cox
2002-02-06 16:58 ` Denis Vlasenko
2002-02-06 13:42 ` Alan Cox
2002-02-06 17:20 ` Christoph Hellwig
2001-12-07 10:12 ` Anton Altaparmakov
2001-12-07 5:40 Kiril Vidimce
2001-12-07 5:58 ` Jeffrey H. Ingber
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=20020206172025.H21624@devserv.devel.redhat.com \
--to=jakub@redhat.com \
--cc=hpa@zytor.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