Thanks for taking me at least minimally seriously, Alan. Pretty generous of you, all things considered.
On 2/23/07, Alan <[EMAIL PROTECTED]> wrote:
That example touches back into user space, but doesnt involve MMU changes or cache flushes, or tlb flushes, or floating point.
True -- on an architecture where a change of TLS does not substantially affect the TLB and cache, which (AIUI) it does on most or all ARMs. (On a pre-EABI ARM, there is even a substantial cache-related penalty for encoding the syscall number in the syscall opcode, because you have to peek back at the text segment to see it, which costs you a D-cache stall.) Now put an sprintf with a %d in it between a couple of the syscalls, and _your_ arch is hurting. Deny the userspace programmer the use of the FPU in threadlets, and they become a lot less widely applicable -- and a lot flakier in a non-wizard's hands, given that people often cheat around the small number of x86 integer registers by using FP registers when copying memory in bulk.
errno is thread specific if you use it but errno is as I said before entirely a C library detail that you don't have to suffer if you don't want to. Avoiding that saves a segment register load - which isn't too costly but isn't free.
On your arch, it's a segment register -- and another who-knows-how-many pages to migrate along with the stack and pt_regs. On ARM, it's a coprocessor register that is incorrectly emulated by most JTAG emulators (so bye-bye JTAG-assisted debugging and profiling), or possibly a register stolen from the general purpose register set. On some MIPSes I have known you probably can't implement TLS safely without a cache flush. If you tell people up front not to touch TLS in threadlets -- which means not to use routines from <stdlib.h> and <stdio.h> -- then implementors may have enough flexibility to make them perform well on a wide range of architectures. Alternately, if there are some things that threadlet users will genuinely need TLS for, you can tell them that all of the threadlets belonging to process X on CPU Y share a TLS context, and therefore things like errno can't be trusted across a syscall -- but then you had better make fairly sure that threadlets aren't preempted by other threadlets in between syscalls. Similar arguments apply to FPU state. IEEE 754. Harp, harp. :-) Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
