RFR: 8225035: Thread stack size issue caused by large TLS size

[Thomas Stüfe]

Hi Florian,

On Wed, Jun 12, 2019 at 2:41 PM Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas Stüfe:
>
> > What I do not understand is: TLS seems to be dynamic memory in the
> > sense that calling pthread_key_create will increase the footprint to
> > be paid (otherwise we would see these problems always, not just with
> > e.g. jemalloc, yes?), so how does adding a static size(is it?) to the
> > stack help with that?
>
> I believe the history is this:
>
> LinuxThreads (the old threading implementation used with glibc) did not
> have a thread pointer.  Instead, it had fixed-size stacks (something
> like 2 MiB) and used bit-masking to find the thread control block at the
> bottom of the stack.
>
> NPTL (the current thread library for GNU/Linux) has a thread pointer
> (which takes various forms, depending on the architecture) and
> variable-sized stacks.  However, the allocation of the TCB (which
> includes static TLS due to ABI necessity) on the stack was kept.  I
> don't know why exactly.  It may save a TLB entry perhaps.  It's not
> advisable to put the TCB on the heap because performance could be very
> poor if there is other data on the same page that is accessed from a
> different NUMA node.
>
> Anyway, what we have today is still the on-stack TCB (with static TLS)
> allocation in NPTL.  So if the user specifies a certain size, the TCB
> area eats into it.
>
> The problem is visible with jemalloc because it uses a lot of static TLS
> (something like 6 KiB, I think).
>
> Does this answer your questions?
>
>
Sorry, no :)

Just additional questions:

What is "static tls", __thread variables? As opposed to what, dynamic tls?
Would that be Posix TLS (pthread_setspecific and friends)? Are the
implementations different? If they are, which TLS does this patch address?

Sorry if I am being slow.

Thanks, Thomas


> Thanks,
> Florian
>