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/
- References:
- [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
- Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]