This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Fix for BZ 22207 -- intermittent failure to create threads on 32-bit machines
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Mon, 25 Sep 2017 23:23:10 -0700
- Subject: Re: [patch] Fix for BZ 22207 -- intermittent failure to create threads on 32-bit machines
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobOc1oypj=cDpFHoL-bCJ8qC9aEPB6RnbSQ7=umAWp4KHw@mail.gmail.com> <f02adb0d-dcba-c264-df1e-88b627e53bb3@redhat.com>
On Mon, Sep 25, 2017 at 11:04 PM, Florian Weimer <fweimer@redhat.com> wrote:
>
> On 09/26/2017 02:09 AM, Paul Pluzhnikov wrote:
>>
>> + /* With default 8MiB Linux stack size, creating 1024 threads can cause
>> + VM exhausiton on 32-bit machines. Reduce stack size of each thread to
>> + 128KiB for a maximum required VM size of 128MiB. */
>> + xpthread_attr_setstacksize (&attr, 128 * 1024);
>
>
> Is there a reason why you do not use PTHREAD_STACK_MIN?
It would possibly work here, but often PTHREAD_STACK_MIN doesn't leave
enough space to run any code at all: the limit is minimal acceptable
to the pthread library, not a "reasonable default if your call chains
aren't deep".
And setting the limit too low opens the test to random out-of-stack
failures depending on how the test is built, what machine it's built
for, etc. etc.
I don't think it's worth trying to get to the absolute minimum here:
most of the stack space will (hopefully) be unused and not allocated
any real memory, and so as long as we stay under 4GiB of VM, the test
should work fine whether PTHREAD_STACK_MIN or 128KiB is used.
--
Paul Pluzhnikov