Michael Schnell wrote: > >It's not true at all that they use a "default" MMU-enabled TLS scheme > >- you need arch-specific kernel support for a context switched memory > >block whether it's with an MMU, or non-SMP without an MMU. > > > I did not look into any code for this. I was told that it should be easy > and not (largely) arch specific to do TLS if you have an MMU and thus I > _supposed_ that an MMU region would be used for TLS which is different > per thread while the other memory is not. This seems quite logical to > me: having the TLS for each thread at the same virtual address and do > the switching in the same way as the process memory is switched (thus > quite "out of the box" and not arch specific).
No, it's not done like that. Linux does not provide thread-specific virtual memory mappings, except for special cases like the vsyscall/vdso page. Some arches have a page which is per-thread, called the vsyscall/vdso kernel page. User-space calls routines in that page. In that page, a pointer to the TLS area might be stored, swapped on context switch by the kernel, and retrieved by calling a routine at a fixed address in the page. The details are always architecture specific, and many archs with MMU use a dedicated register for TLS because it's faster and simpler. ARM Linux uses both techniques, depending on the architecture revision. On no-MMU architectures, the "swap on context switch" method with vdso kernel page can still be used, but generally it isn't because NPTL TLS is implemented alongside ELF DSO support, and that's always been done so far using a dedicated register on no-MMU architectures (FDPIC). It is easier to get the vdso method working with an MMU, I agree. > >Maybe not slower, but larger, surely? > > I suppose so, but nowadays, memory is not a real issue any more... :-) . It is on some embedded systems. But I've forgotton what we were talking about :-) -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
