> Please note that the aio helper thread *should* be using a default 2MB stack on
> x86, not 16K, I don't see anywhere that sets the helper threads stack to 16K.
The helper thread stack size *is* set by __pthread_get_minstack.
The test case here no longer crashes using the current git trunk, but only
because the aio thread stack is now increased to accomodate static tls:
> You are also increasing the memory footprint of all applications that use TLS
> that worked fine before.
It depends on what you call "memory footprint". Yes, we'll increase memory
we *reserve* for stacks (VM size). But we will not *use* any more memory
than what's already used (RSS).
I think the only application that would notice this is one that was almost
running out of VM space. An answer for such app would be to decrease its
default stack sizes, use smaller number of threads, or switch to 64 bits.
> Before making any changes we need to hear from the distros (RH, SuSE, Debian,
> Gentoo, Ubuntu etc) about the kind of impact this might have e.g. a quick find
> / readelf -a / grep to determine on average the memory increase we are looking
> at.
Would above still apply if it's just VM size we are talking about?
I don't see how readelf will reveal anything.
> There are multiple cases here.
> You appear to be suggesting the following:
>
> For (a) the behaviour remains the same.
>
> For (b) we adjust upward by the size of the static TLS data.
>
> For (c) "
>
> For (d) "
>
> For (e) "
(In reply to comment #8)
> Please note that the aio helper thread *should* be using a default 2MB stack on
> x86, not 16K, I don't see anywhere that sets the helper threads stack to 16K.
The helper thread stack size *is* set by __pthread_ get_minstack.
The test case here no longer crashes using the current git trunk, but only
because the aio thread stack is now increased to accomodate static tls:
// nptl/nptl-init.c get_minstack (const pthread_attr_t *attr)
size_t
__pthread_
{
struct pthread_attr *iattr = (struct pthread_attr *) attr;
return (GLRO(dl_pagesize) + __static_tls_size + PTHREAD_STACK_MIN
+ iattr->guardsize);
}
This was done here:
2011-12-22 Ulrich Drepper <email address hidden>
[BZ #13088] unix/sysv/ linux/timer_ routines. c: Get minimum stack size get_minstack. initialize_ minimal_ internal) : Get page size
(__pthread_ get_minstack) : New function. get_minstack. get_minstack.
* sysdeps/
through __pthread_
* nptl-init.c (__pthread_
directly from _rtld_global_ro.
* pthreadP.h: Declare __pthread_
* Versions (libpthread) [GLIBC_PRIVATE]: Add __pthread_
and is *precisely* the change we are asking for for the other threads.
I see that Rich Felker is in exact agreement with me: sourceware. org/bugzilla/ show_bug. cgi?id= 13088#c1
http://
> You are also increasing the memory footprint of all applications that use TLS
> that worked fine before.
It depends on what you call "memory footprint". Yes, we'll increase memory
we *reserve* for stacks (VM size). But we will not *use* any more memory
than what's already used (RSS).
I think the only application that would notice this is one that was almost
running out of VM space. An answer for such app would be to decrease its
default stack sizes, use smaller number of threads, or switch to 64 bits.
> Before making any changes we need to hear from the distros (RH, SuSE, Debian,
> Gentoo, Ubuntu etc) about the kind of impact this might have e.g. a quick find
> / readelf -a / grep to determine on average the memory increase we are looking
> at.
Would above still apply if it's just VM size we are talking about?
I don't see how readelf will reveal anything.
> There are multiple cases here.
> You appear to be suggesting the following:
>
> For (a) the behaviour remains the same.
>
> For (b) we adjust upward by the size of the static TLS data.
>
> For (c) "
>
> For (d) "
>
> For (e) "
Yes, I believe that's what we are proposing.