[PATCH] Async signal safe TLS accesses
Carlos O'Donell
carlos@redhat.com
Sat Nov 30 07:57:00 GMT 2013
On 11/28/2013 08:03 PM, Alexandre Oliva wrote:
> On Nov 19, 2013, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
>
>> On Wed, Nov 13, 2013 at 7:45 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
>>> Ping?
>>> https://sourceware.org/ml/libc-alpha/2013-11/msg00183.html
>
>> Ping? Ping?
>
> Apologies for the delay in this review.
>
> I'm a bit disappointed at how wasteful the allocation strategy is,
> wasting a full page per thread even for a one-word TLS dynamic block. I
> think using a TLS-only malloc arena, only locked with signals disabled,
> would bring us much better memory efficiency, although there might be a
> significant penalty for assigning dynamic segments of different threads
> to the same page, should they happen to be accessed very often. This
> page sharing by different threads is something we don't necessarily
> avoid with the current AS-Unsafe allocation scheme, and avoiding that is
> an improvement that the current strategy brings, but I wonder if we
> could find some trade off that wouldn't waste so much memory but that
> would keep segments used by different threads in separate pages... This
> first comment is not meant as a blocker against the page, but as a
> suggestion for future improvement.
I agree it's wasteful, but it has a purpose.
The one page is wasted for the sake of simplicity of implementation
and maintenance. The more complex this code becomes the harder it
is to review for AS-safety.
We could gain that page back by optimizing our stack allocation layout
in nptl/allocatestack.c which at present is a big mess. Not to mention
we should split out the TLS static block from the stack so that stack
analysis tools work correctly (see
https://sourceware.org/bugzilla/show_bug.cgi?id=11787)
Cheers,
Carlos.
More information about the Libc-alpha
mailing list