This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses

On 11/28/2013 08:03 PM, Alexandre Oliva wrote:
> On Nov 19, 2013, Paul Pluzhnikov <> wrote:
>> On Wed, Nov 13, 2013 at 7:45 AM, Paul Pluzhnikov <> wrote:
>>> Ping?
>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]