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

[Florian Weimer]

* 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?

Thanks,
Florian