----- On Jul 14, 2015, at 5:34 AM, Ben Maurer bmaurer@xxxxxx wrote: > Mathieu Desnoyers wrote: >> If we invoke this per-thread registration directly in the glibc NPTL >> implementation, >> in start_thread, do you think it would fit your requirements ? > > I guess this would basically be transparent to the user -- we'd just need to > make sure that the registration happens very early, before any chance of > calling malloc. Yes, this is my thinking too. > > That said, having the ability for the kernel to understand that TLS > implementation are laid out using the same offset on each thread seems like > something that could be valuable long term. Doing so makes it possible to build > other TLS-based features without forcing each thread to be registered. AFAIU, using a fixed hardcoded ABI between kernel and user-space might make transition from the pre-existing ABI (where this memory area is not reserved) a bit tricky without registering the area, or getting a "feature" flag, through a system call. The related question then becomes: should we issue this system call once per process, or once per thread at thread creation ? Issuing it once per thread is marginally more costly for thread creation, but seems to be easier to deal with internally within the kernel. We could however ensure that only a single system call is needed per new-coming thread, rather than one system call per feature. One way to do this would be to register an area that may contain more than just the CPU id. It could consist of an expandable structure with fixed offsets. When registered, we could pass the size of that structure as an argument to the system call, so the kernel knows which features are expected by user-space. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
