Messages in this thread | | | Date | Wed, 06 Feb 2002 14:05:52 -0800 | From | "H. Peter Anvin" <> | Subject | Re: 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/
| |