lkml.org 
[lkml]   [2002]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel: ldt allocation failed
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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.119 / U:1.952 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site