From: "H. Peter Anvin" <hpa@zytor.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel: ldt allocation failed
Date: Wed, 06 Feb 2002 14:05:52 -0800 [thread overview]
Message-ID: <3C61A8C0.7000406@zytor.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>
Jakub Jelinek 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.
-hpa
next prev parent reply other threads:[~2002-02-06 22:06 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 [this message]
2002-02-06 22:20 ` Jakub Jelinek
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=3C61A8C0.7000406@zytor.com \
--to=hpa@zytor.com \
--cc=jakub@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.